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1.  Introduction 


This  report  describes  the  model  developed  by  the  Research  Triangle  Institute  (RTI) 
and  Virginia  Polytechnic  Institute  (VPI)  under  TRW  subcontract  Number  FF9327VBOS. 
The  objective  wa^  to  develop  and  demonstrate  an  executable  model  of  configuration 
and  reconfiguration  of  the  Ada  Avionics  Real  Time  System  (AARTS)  lonning  on  the 
Wright  Laboratories  VHSIC  Avionics  Multiprocessor  (VAMP)  demonstration  hard¬ 
ware.  The  model  was  developed,  using  the  Architecture  Design  and  Assessment  Sys¬ 
tem  (ADAS)  delivered  and  executed  using  GIPSIM  simulation.  This  report  describes 
the  model  in  detail  and  provides  examples  that  show  the  usefulness  of  developing 
an  executable  model  in  parallel  with  system  design.  The  modeling  effort  and  model 
execution  serve  to  validate  (or  invalidate)  design  decisions  as  they  are  made. 

The  model  was  constructed  from  information  contained  in  numerous  .\ARTS  devel¬ 
opmental  documents  and  internal  documents  and  reference  furnished  by  the  TRW 
project  manager.  This  was  reinforced  by  regular  technical  exchange  discussions  be¬ 
tween  the  RTI  and  TRW  project  managers.  In  addition  to  two  formal  demonstrations 
of  the  model,  a  thorough  review  was  conducted  with  the  principle  members  of  the 
A.\RTS  development  team  in  January  1991.  This  review  and  the  attendance  of  the 
AARTS  development  team  at  the  demonstrations  served  to  verify,  at  each  point,  that 
the  ADAS  model  is  a  true  representation  of  the  design  as  it  exists  (or  is  visualized) 
at  that  point. 


I 


This  report  is  intended  for  users  who  want  to  employ  the  model  for  continuing  analysis 
of  AARTS  development  and  expansion  and,  possibly,  as  a  point  of  departure  for 
follow-on  developments.  It  is  assunied  that  the  reader  is  familiar  with  the  basic 
AARTS  architecture  and  functioning,  as  well  as  that  of  the  VAMPs.  The  report 
focuses  on  the  model  -  how  functions  are  simulated,  how  resource  utilization  was 
estimated,  and  how  the  execution  is  controlled.  These  subjects  are  addressed  in 
considerable  detail  to  provide  a  reader,  who  is  familiar  with  the  ADAS  tool  set,  with 
sufficient  understanding  of  the  model  so  that  he  can  make  the  necessary  changes  to 
analyze  the  impact  of  changes  in  AARTS  design,  hardware  capability,  or  function 
resource  requirements.  It  should  also  provide  a  background  for  expansion  of  the 
model  to  a  more  extensive  set  of  applications,  a  larger  or  more  complex  hardware 
architecture,  or  both. 

The  final  three  sections  provide  examples  of  model  outputs  and  analyses,  an  approach 
for  expanding  the  model,  and  the  types  of  errors  that  can  be  detected  early  in  the 
design  with  an  ADAS  modeling  effort. 

1.1.  Background 

Under  contract  from  the  U.S.  Air  Force,  TRW  is  developing  the  A  ARTS  operating 
system  for  Wright  Laboratory.  AARTS  is  the  implementation  of  the  PAVE  PILLAR 
Operating  System  and  system  management  concept.  The  AARTS  is  targeted  for  the 
laboratory  VHSIC  Avionic  Modular  Processors  (VAMP)  being  developed  by  West- 
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inghouse  Electric  Company  (WEC).  The  ADAS  model  developed  in  this  effort  is  to 
be  calibrated  with  AARTS  Demonstration  3  and  then,  in  a  second  phase,  expanded  to 
represent  the  entire  PAVE  PILLAR  mission  application  architecture.  GIPSIM  sim¬ 
ulation  of  the  expanded  model  will  provide  an  assessment  of  specific  hardware  and 
software  partitioning  needs  to  meet  the  PAVE  PILLAR  specification.  Of  particular 
interest  is  the  Block  Transfer  Bus  utilization  and  the  total  time  it  takes  to  com¬ 
plete  various  processes  associated  with  system  startup  and  reconfiguration  following 
module  failure. 

The  distributed  architecture  of  PAVE  PILLAR  will  provide  for  maximum  utilization 
of  common  hardware  and  software  programs,  as  well  as  providing  maximum  reliability, 
maintainability,  and  support  for  both  air-to-air  and  air-to-ground  missions.  During 
development  this  model  has  served  to  highlight  issues  or  deficiencies  in  early  design 
decisions  by  addressing,  in  a  system  context,  hard  ware/ software  interfaces.  Once  cali¬ 
brated  and  validated  against  an  implemented  AARTS  System  it  will  provide  the  basis 
for  simulation  and  analysis  of  the  PAVE  PILLAR  architecture  with  developmental 
avionics  processes  integrated  into  an  expanded  suite  of  VAMP  or  VAMP-like  clusters. 

1.2.  ADAS  Model  Of  AARTS;  An  Overview 

The  Ada  Avionics  Real  Time  System  (AARTS)  is  the  evolving  implementation  of 
the  PAVE  PILLAR  operating  system  concept.  The  AARTS  is  divided  into  three 
top-level  computer  software  components  (TLCSCs)  called  executives.  The  kernel  ex- 
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ecutive  TLCSC  manages  the  resources  of  a  single  VHSIC  module.  It  is  the  operating 
system  for  the  module.  The  Distributed  Executive  TLCSC  provides  the  services  for 
communication  between  modules.  Versions  of  the  distributed  executive  for  CPU. 
high-speed  databus  interface,  M1553B  bus  interface  and  mass  memory  modules  dif¬ 
fer.  The  difference  is  normally  the  presence  of  a  component  associated  with  a  specific 
interface  (i.e.,  bus)  or,  in  the  case  of  CPU’s,  the  functionality  needed  to  establish 
message  connections.  The  third  major  component  of  AARTS  is  the  System  Execu¬ 
tive  TLCSC.  This  component  contains  the  software  that  manages  the  system.  This 
component  can  function  as  a  cluster  supervisor,  managing  a  cluster  of  modules;  as  the 
system  supervisor;  managing  the  system;  or  as  a  hot  backup  for  the  system  supervi¬ 
sor.  The  targeted  VHSIC  Avionic  Modular  Processor  (VAMP)  consists  of  five  VHSIC 
modules,  each  containing  a  16-bit  VI 750 A  processor  with  128  or  256K  of  memory. 
The  memory  in  each  module  has  been  divided  into  numbered  address  states  (AS)(i.e., 
ASO,  ASl,  etc.).  The  lowest  address  State,  ASO,  is  reserved  for  the  basic  operating 
system.  This  consists  of  the  kernel  executive,  the  distributed  executive  and  the  kernel 
unit  of  the  system  executive.  This  is  referred  to  as  the  ASO  Software  throughout  this 
report.  (Most  of  the  lower  level  software  components  of  the  ASO  software  contain  an 
I/O  interface  unit  that  is  resident  in  any  address  State  that  can  call  for  the  TLCSC 
services). 

Address  states  one  and  higher  can  contain  any  loadable  program  unit  (LPU).  The 
system  executive  (less  the  kernel)  is  loaded  in  ASl  by  cluster  supervisors  upon  winning 
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arbitration.  Assumption  of  the  role  of  System  Supervisor  or  hot  backup  only  requires 
enabling  additional  units.  This  Supervisory  Software  is  referred  to  as  the  ASl  software 
through  the  remainder  of  this  report. 

The  AARTS  development  program  includes  several  demonstrations.  These  demon¬ 
strations  progress  from  operating  a  single  module  through  a  several  cluster  effort  with 
dynamic  LPU  loading.  Demonstration  3  was  to  be  conducted  on  two  VHSIC  Avionic 
Modular  Processor  (VAMP)  clusters.  The  clusters  are  currently  connected  to  a  simu¬ 
lated  System  Mass  Memory  and  to  one  another  via  high-speed  fiber  optic  data  busses. 
Each  VAMP  contains  five  processor  modules  that  communicate  with  one  another  via 
a  Pl-bus.  The  five  modules  consist  of  two  CPU  modules,  two  high-speed  databus 
interface  modules  and  a  M1553B  bus  interface  module.  Demonstration  3  was  to  start 
the  system,  execute  a  guidance  and  navigation  scenario  consisting  of  five  LPUs,  and 
demonstrate  recovery  from  failure. 
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RTI  principal  investigator  on  methods  for  system  abstraction  and  reviewed  and  cri¬ 
tiqued  the  model  at  strategic  points  in  the  development.  Dr.  Tennis  S.  White,  then  at 
VPI,  currently  with  IBM  Glendale  Research  Laboratory,  produced  the  actual  graphs. 
Dr.  White  devised  the  control  schemes  to  be  described  later  in  this  report.  Mr. 
J.L.  Stautberg,  of  TRW  Dayton  Engineering  Laboratory,  served  as  project  monitor 
and  liaison  between  the  modeling  team  and  the  AARTS  development  team.  Finally, 
Mr.  Joseph  Wilgus  of  Wright  Laboratory  provided  oversight  and  coordination  of  the 
entire  effort,  a  task  of  much  more  significance  and  value  than  this  simple  statement 
can  convey. 
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2.  The  ADAS  Product 


ADAS  is  a  set  of  computer-aided  design  tools  for  the  synthesis  and  analysis  of  soft¬ 
ware  algorithms  and  their  hardware  implementations  at  the  architectural  level.  ADAS 
models  hardware  and  software  using  directed  graphs  in  which  nodes  represent  individ¬ 
ual  software  operations  or  hardware  functional  elements  and  arcs  represent  data  and 
control  flow  paths.  Color-coded  connection  points  called  ports  indicate  the  direction 
of  flows  along  arcs.  Nodes  and  arcs  are  typed  and  have  a  number  of  attributes  associ¬ 
ated  with  them.  Nodes  can  be  expanded  into  subgraphs  that  represent  the  refinement 
of  a  software  operation  or  hardware  component  into  a  set  of  lower  level  operations 
or  components  and  their  interconnections.  Nodes  with  subgraphs  are  called  internal 
nodes]  nodes  without  subgraphs  are  called  leaf  nodes. 

Simulation  is  controlled  on  a  graph  or  graph  hierarchy  by  the  movement  of  units 
called  tokens  around  the  graphs.  During  simulation,  nodes  produce  and  consume 
tokens  and  arcs  act  as  FIFO  queues  of  tokens. 

Using  this  ADAS  model,  the  user  can  test  alternative  algorithm  and  architecture 
strategies  measuring  performances,  latency,  timing,  resource  utilization,  etc. 

2.1.  How  the  ADAS  Tools  Interact 

Data  flows  between  the  ADAS  tools  and  the  data  base  files  which  are  illustrated  in 
Figure  A-1.  In  this  diagram,  circles  represent  individual  ADAS  tools;  directed  lines 
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represent  data  flows  between  the  tools  and  individual  data  base  files,  the  contents 


of  which  are  described  between  paired  horizontal  lines;  and  boxes  represent  analysis 
processes  outputs.  ADAS  system. 


The  numbers  on  program  circles  in  Figure  A-1  represent  the  order  in  which  the  ADAS 
tools  would  typically  be  executed  during  a  single  design  cycle.  The  design  process 
typically  consists  of  a  number  of  iterations  of  the  cycle.  A  design  is  analyzed  and 
its  execution  simulated,  and  the  results  are  used  to  modify  and  refine  the  design. 
This  analysis/refinement  process  is  repeated  until  the  design’s  performance  meets 
specification.  Each  circle  in  the  diagram  illustrates  one  or  more  phases  of  the  design 


process; 


1.  EDIGRAF 


2.  CONCH 


3.  GIPSIM 


4.  XPETRI 


5.  ASH 


The  directed  graph  editor  creates  the  initial  template  and 
graph  data  base  files  for  the  hardware  and  software  de¬ 
sign  graphs;  it  is  also  used  to  make  modifications  to  the 
templates,  graph  structure,  and  node  and  arc  attributes 
throughout  the  iterative  design  process. 

The  design  graph  consistency  checker  verifies  that  graph 
data  flows  are  consistent  (e.g.,  that  component  types 
match)  and  optionally  checks  graph  attribute  values 
against  template  values. 

The  directed  graph  simulator  performs  initial  verification 
of  software  graphs;  it  verifies  that  nodes  are  firing  in  the 
correct  order,  that  token  produce  and  consume  values 
are  correct,  and  that  firing  frequencies  are  approximately 
correct. 

The  performance  analysis  program  generates  petri  net 
models  of  software  directed  graphs  for  detailed  analysis 
of  design  performance.  If  the  performance  is  not  satisfac¬ 
tory,  the  software  can  be  modified  with  EDIGRAF,  and 
the  design  cycle  repeated. 

The  task  allocation  tool  assigns  hardware  graph  compo¬ 
nents  to  software  graph  operations. 
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6-7.  CSIM/ADASIM 


A  design  graph  functional  simulator  generation  program 
constructs  a  program,  CSIM  or  ADASIM,  to  simulate  ex¬ 
ecution  of  the  design  from  functional  descriptions  of  the 
individual  design  graph  nodes  in  the  C  or  Ada  program¬ 
ming  language. 

8.  ISPGEN /HELIXGEN  Finally,  a  hardware  design  language  generator  constructs 

a  program  to  simulate  execution  of  the  hardware  design 
from  functional  descriptions  of  the  individual  hardware 
design  graph  nodes  in  the  ISPS  or  HELIX  language. 

The  individual  files  that  form  the  ADAS  common  data  base  are  shared  by  the  tools 

that  comprise  the  ADAS  system  and  form  the  basis  of  the  tools’  integration  into  a 

coherent  system  for  software/hardware  codesign.  The  data  base  includes  template 

data  bases  which  contain  representations  of  the  basic  building  blocks  that  are  used 

to  construct  graph  data  bases.  The  latter  contain  the  data  that  define  the  positions 

and  interconnections  of  nodes  and  arcs  in  software  and  hardware  design  graphs. 


2.2.  Graph,  Node,  Arc  and  Port  Attributes 


The  behavior  of  the  checking,  mapping,  and  simulation  tools  is  controlled  by  the 
topology  (connectivity)  of  the  graphs  and  by  attributes  assigned  to  the  graphs,  the 
nodes  and  their  ports,  and  the  arcs.  The  topology  and  attributes  are  assigned  and/or 
modified  using  the  (EDIGRAF)  graphics  editor.  Initially,  attributes  are  inherited 
from  the  default  values  contained  in  the  template  for  the  element.  In  this  paragraph 
the  attributes  associated  with  the  graph  objects  are  reviewed  to  provide  background 
for  the  discussion  of  the  models  in  the  remainder  of  the  report. 

lor  this  discussion,  attributes  are  divided  into  two  major  classes,  those  assigned  by 
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the  ADAS  tools  and  not  modifiable  by  the  modeler  and  those  assigned  and  modifiable 
by  the  modeler.  The  latter  category  has  been  divided  into  six  subcategories  and  will 
be  discussed  first. 


The  first  subcategory,  display  attributes,  serve  primarily  to  help  make  the  graphs 
readable  and  understandable.  These  attributes  are  listed  in  Table  2.1. 


Table  2.1.  Display  Attributes 


Graph  Node  Arc 

graphjiame  node_name*  arc_name* 

node_color  arc_color 

node-height  first-joint 

node-width  . 

node  orientation  fifth-joint 

*Used  by  checking  and  simulation  tools  to  identify  output 


Each  graph,  node,  and  arc  has  a  name  attribute.  The  graph  name  is  optional  text  and 
shows  up  as  a  banner  at  the  top  of  the  graph  on  the  monitor.  Any  legal  text  entry  can 
be  chosen  for  a  graph  name.  Legal  ADAS  text  is  defined  on  pages  3-30  of  the  ADAS 
User  Manual  [4].  The  nodes  and  arcs  are  also  named.  These  names  must  be  unique 
(the  default  name  is  the  template  name  followed  by  a  unique  number)  since  they  are 
used  extensively  to  identify  output  statistics  from  the  ADAS  tools.  Node  and  arc 
names  can  be  any  unique  legal  ADAS  label.  Legal  ADAS  labels  are  defined  on  pages 
3-30  of  the  ADAS  User  Manual  [4].  A  color  can  be  selected  for  each  node  and  arc 
from  the  ADAS  16  color  palette.  These  colors  are  used  to  enhance  understanding  of 
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the  graphs.  The  height  and  width  of  a  node  in  grid  units  can  be  selected  to  improve 
appearance.  ADAS  nodes  are  constructed  with  all  input  ports  on  one  side  and  all 
output  ports  on  the  opposite  side.  Node  orientation  representing  the  direction  of  flow 
through  the  node  can  be  selected  as  down  (default),  up,  right,  or  left.  An  arc  can  be 
drawn  with  a  maximum  of  five  joints  (direction  changes  between  the  source  outport 
and  sink  inport).  The  coordinates  of  these  joints,  if  any,  are  stored  as  arc  attributes. 

The  second  subcategory,  connectivity  attributes,  are  used  primarily  to  support  con¬ 
version  of  a  hierarchy  of  graphs  into  a  single  executable  model.  This  model,  consisting 
of  all  of  the  connected  leaf  nodes,  is  referred  to  as  the  flattened  graph  or  flattened 
model.  These  attributes,  shown  in  Table  2.2,  are  also  used  extensively  by  the  checking 
and  validation  routines. 


Table  2.2.  Connectivity  Attributes 


Node 

Node  Port 

Arc 

node_class 

inportjd 

token_data_type 

subgraf-filejiame 

outportJd 

arcJemplate 

graph_port_n  umber 

in_token_data_type 

node_template 

out_token_data_type 

The  attrib’ite  node^class  indicates  how  the  node  functions  in  the  model.  It  may  have 
value  of  leaf,  a  node  which  maps  to  a  specific  hardware  model;  internal,  a  node  which 
has  a  subgraph  to  be  expanded  within  the  executable  model;  or  inport/outport,  a 
node  that  represents  an  inport/outport  on  the  parent  level  graph  node.  If  a  node  is 
of  node  clciss  internal  it  must  have  the  file  name  for  the  subgraph  in  the  attribute 
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subgraf.file.name.  Port  attributes  are  actually  a  part  of  the  node  data.  A  set  of 
attributes  for  each  input  and  output  port  is  contained  in  each  node  database.  Since 
these  port  attributes  carry  information  critical  to  simulation  and  since  there  can  be 
many  ports  on  a  given  node,  the  port  attributes  have  been  placed  in  a  separate 
column  in  the  tables  presented  in  this  section.  The  first  port  attribute  of  interest 
is  the  in  (out) ported.  Inports  and  outports  of  a  node  are  uniquely  identified  by  a 
number  from  zero  to  the  number  of  in  (out)  ports  minus  one,  clockwise  for  inports 
and  counterclockwise  for  outports  (left  to  right  when  orientation  is  down).  On  a 
subgraph  of  a  node,  there  must  be  one  graph  port  node  for  each  inport  and  outport 
on  the  parent  node.  The  graphjportjnumbtT  is  the  number  of  the  associated  port  on 
the  parent  node.  Each  in  (out)  port  has  an  associated  in(out)Joken.dataJype.  This 
dataJype  may  be  any  legal  ADAS  identifier.  Each  arc  has  a  token.dataJype  attribute. 
This  attribute  must  match  the  dataJype  attribute  of  both  the  source  and  sink  ports 
before  a  connection  can  be  made.  Finally,  the  checking  tools  will  warn  one  if  the  node 
or  arch  template  identified  in  the  attribute  nodeJemplate  or  arcJemplate  does  not 
match  the  node  or  arc.  This  usually  occurs  when  attributes  of  a  node,  port,  or  arc 
have  been  edited  subsequent  to  creation  and  a  new  template  has  not  been  referenced 
and/or  developed. 

The  third  subcategory  is  those  attributes  of  the  software  model  employed  by  the 
simulation  tools,  particularly  GIPSIM,  which  is  the  tool  most  applicable  at  this  stage 
to  the  AARTS  Demonstration  Model.  These  attributes  are  listed  in  Table  2.3. 
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Table  2.3.  Simulation  Attributes 


Graph 

Node 

Node  Port  Arc 

time.unit 

hardware_module 

firing-threshold  queuejsize 

conversionJactor 

execution-order 

token  -prod  uce-rate 

firing-delay 

token_consume_rate 

trace-flag 

node-user-text 

initial-token -Count 

Two  attributes  of  the  graph  relate  to  the  time  steps  used  in  a  simulation.  The  at¬ 
tribute  time.unit  is  a  label  documenting  the  units  in  which  firing  delays  are  calculated 
for  the  nodes.  The  attribute  conversionjactor  is  a  floating  point  number  that  relates 
the  time  unit  for  a  subgraph  to  the  time  unit  of  the  parent  graph.  The  node  attribute 
hardware.module  for  a  software  node  contains  the  name  of  the  node  in  the  hardware 
model  onto  which  the  software  node  is  mapped.  This  is  a  many  to  one  mapping,  i.e.. 
any  number  software  nodes  may  be  mapped  to  a  single  hardware  node  (resources) 
but  each  software  node  may  be  mapped  to  only  one  hardware  node.  The  software 
node  attribute  execution.order  is  an  integer  establishing  queuing  priority  for  solving 
hardware  module  contention  during  simulation.  The  node  attribute  firiiig.dflay  is  the 
number  of  time  units  the  node  waits  once  it  has  received  its  resource  until  the  resource 
is  released.  Alternatively,  it  is  the  time  the  node  waits  before  firing  (producing  its 
output  tokens)  after  it  is  primed.  The  attribute  trace.flag  is  a  flag  that  when  set  gen¬ 
erates  a  simulation  output  listing  the  schedule  of  all  primings  and  firings  of  a  node. 
The  attribute  node.userjeit  may  contain  any  text  entered  by  the  user.  This  attribute 
may  be  accessed  by  CSIM  or  AdaSIM.  If  its  value  is  set  to  “any,”  all  simulations  treat 
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it  as  an  OR-node  (the  node  is  enabled  whenever  any  rather  than  ^  of  its  in  ports 
has  reached  its  firing  threshold).  The  node  input  port  attributes  firingjhreshold  and 
token.consume^rate^  along  with  the  output  port  attribute  token^produce_rnte,  provide 
the  data  necessary  to  control  and  synchronize  execution  of  the  GIPSIM  simulation.  A 
node  is  enabled  when  each  (any  in  the  case  of  an  OR-node)  of  its  input  arcs  contains  a 
number  of  tokens  in  its  queue  greater  than  or  equal  to  the  inport  firingjhreshold.  The 
node  then  “contends”  for  its  hardware  resource  (the  attribute  execution.order  orders 
any  queue  for  the  resource).  When  the  resource  is  available  the  node  becomes  primed 
and  removes  a  number  of  tokens  equal  to  the  token^consumejrate  from  the  arc  queue 
at  each  of  its  input  ports.  After  a  delay  equal  to  the  attribute  firing.delay,  the  node 
“fires”  placing  a  number  of  tokens  equal  to  the  token.produce.rate  on  the  arc  queue  at 
each  output  port.  At  this  point  the  next  enabled  node  in  the  hardware  model  queue, 
if  any,  can  be  primed.  To  initialize  feedback  loops  or  for  other  scheduling  purposes, 
it  is  often  necessary  to  place  one  or  more  tokens  in  an  arc  queue  at  the  start  of  the 
simulation.  This  is  accomplished  with  the  input  port  attribute  initiaUoken.count. 
The  arc  attribute  queue^size  limits  the  number  of  tokens  that  may  exist  at  any  time 
in  the  arc  queue.  If  firing  of  a  node  would  result  in  exceeding  queue  size  on  any  arc 
for  which  it  is  the  source,  the  node  is  “blocked”  and  may  not  be  primed  until  this 
condition  is  removed. 

Five  attributes  are  employed  by  functional  simulations,  but  not  by  GIPSIM.  These 
attributes  are  listed  in  Table  2.4 
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Table  2.4.  CSIM/AdaSIM  Attributes 


Node 

Node  Port 

Arc 

packageJi  le_n  ame 

in_token_data_type 

out_token_data_type 

token_data_type 

token.units 

The  port  and  arc  attributes  identify  “types.”  The  node  attribute  package.Jile.narne 
identifies  the  module  source  file  to  be  used  by  CSIMGEN,  AdaSIMGEN,  HELIXGEN. 
and  ISPGEN  for  simulation  generation. 


Table  2.5  contains  a  list  of  attributes  used  primarily  for  storage  of  user  information. 
The  functional  simulations  can  be  made  to  access  these  attributes  as  part  of  the 
simulation.  For  each  graph,  node,  and  arc  there  are  four  attributes  provided  to  store 
a  floating  point  number,  an  integer,  text,  oi  a  file  name. 


Table  2.5.  Infoinieaioii  Attributes 


Graph 

Node 

Arc 

graph.userJloat 

node.userJloat 

arc_user_float 

graph_user_text 

node_user_text 

arc_user_text 

graph_user_integer 

node_userJnteger 

arc_user  integer 

graph_user_file_name 

node_user_file_name 

arc_user_tilejiame 

Finally,  one  node  attribute,  module.class,  assigns  hardware  and  .software  nodes  to 
user  labeled  classes.  This  attribute  specifies  the  hardware  module  class  to  which  a 
software  node  may  be  mapped  by  the  automatic  software  to  hardware  mapping  tool. 
ASH. 
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The  second  category  consists  of  those  attributes  written  to  the  database  by  the  simu¬ 
lation  tools.  These  attributes  are  updated  by  the  simulation  program.  Node  and  arc 
attributes  indicating  activity  or  activity  level  can  be  displayed  by  color  coding  (cold 
to  hot  colors)  on  the  graphic  screen.  The  screen  is  constantly  updated  with  these 
color  codes  during  a  simulation  run  providing  an  animated  picture  of  what  is  going 
on.  The  program  produced  attributes  are  shown  in  Table  2.6. 


Table  2.6.  Tool  Output  Attributes 


Node 

Arc 

node-utilization 

current_token_count 

module.utilization 

aver  age_token_coun  t 

nodejatency 

maximum_token_count 

times  Jired 

token_access_count 

when_next_available 

simulationjstatus 

status_message 

The  attribute  node.utilization  gives  the  percent  of  the  time  units  during  the  sim¬ 
ulation  that  the  node  was  busy.  The  attribute  module.utiiization  is  the  same  as 
node.utilization  for  a  hardware  graph.  For  a  software  graph  module.utilization  is  the 
utilization  of  the  hardware  module  to  which  the  node  is  mapped.  NodeJatency  is  the 
earliest  time  that  a  node  can  finish  execution.  The  attribute  times.fired  is  the  number 
of  times  a  node  fired  during  the  simulation. 


The  attribute  when.nexLavailable  is  the  time  unit  in  the  execution  cycle  during  which 
the  hardware  node  (or  the  hardware  module  associated  with  a  software  node)  becomes 
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available.  A  value  of  zero  indicates  the  module  was  never  used.  A  value  less  than 


the  current  simulation  time  indicates  the  module  is  not  in  use  and  has  been  available 
since  the  time  indicated.  A  value  greater  than  the  current  time  indicates  the  module 
is  in  use  and  will  not  become  available  until  the  time  indicated. 

The  attribute  simulation^status  shows  the  node’s  status  at  the  end  of  the  simulation. 
This  attribute  may  have  a  value  of: 

•  INIT  -  node  has  not  been  blocked,  primed  or  enabled  yet. 

•  BLOCKED  -  node  cannot  fire  (reason  given  by  statusjnessage  attribute). 

•  PRIMED  -  node  is  primed. 

•  INACTIVE  -  node  is  set  to  non-firable  by  a  user  (by  a  procedure  in  CSIM  or 
AdaSIM). 

•  ENABLED  -  node  is  enabled. 

The  statusjmessage  attribute  is  a  short  text  message  describing  why  a  blocked  node 
is  blocked. 

Four  arc  attributes  are  set  by  the  simulation  program.  These  four  are  the  cur- 
renLtoken.count  on  the  arc’s  queue  when  the  simulation  ended;  the  average  number 
of  tokens  on  the  arc’s  queue  at  any  point  during  the  simulation;  the  maximum  number 
of  tokens  in  the  arc’s  queue  at  any  point  during  the  simulation;  and  the  number  of 
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times  tokens  were  placed  into  or  removed  from  the  arc’s  queue  by  its  source  and  sink 
nodes  during  the  simulation. 
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3.  Description:  ADAS  Model  Of  AARTS 


The  focus  of  the  ADAS  model  was  on  the  performance  of  the  I/O  and  message 
passing  services  of  AARTS,  rather  than  the  run  time  system  itself.  A  complete  set  of 
design  specifications  was  provided  by  TRW.  Documentation  was  also  provided  for  the 
target  hardware,  the  Block  Transfer  bus,  the  PTbus,  and  the  VHSIC  modules.  From 
this  documentation  and  discussions  with  TRW  engineers,  RTI  and  VPI  developed  an 
ADAS  model  representing  the  AARTS  process. 

This  description  of  the  ADAS  model  is  organized  into  major  processes  before,  during, 
and  after  reconfiguration,  namely,  (i)  the  startup  process,  (ii)  the  system  messages 
component,  (iii)  normal  operations,  (iv)  reconfiguration  following  failure  of  a  CPU, 
and  (v)  the  shutdown  process. 

3.1.  Assumptions  and  Conventions 

3.1.1.  Assumptions 

The  ADAS  model  assumes  that  the  Block  Transfer  Bus  Interface  Modules  (BTBlMs) 
in  each  cluster  will  be  actively  loaded  (loaded  over  the  HSDB)  with  their  entire 
software  load.  Following  this,  each  BTBIM  will  support  passive  loading  (loading 
over  the  PTbus)  of  the  remaining  modules  in  their  cluster.  The  first  modules  to  be 
passively  loaded  are  the  Mission  Avionic  Bus  Interface  Modules  (MABIMs).  This 
ensures  that  inter-cluster  communication  will  exist  before  the  arbitration  process 
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commences  and  prevents  the  likelihood  of  two  separate  system  supervisors  being 
established. 

In  the  model,  the  sequence  of  loading  ASO  into  the  CPU  modules  is  controlled.  This 
predetermines  the  system  supervisor  (CPU22).  This  controlled  sequencing  also  pre¬ 
determines  the  system  hot-backup^  (CPU12).  As  presently  configured,  the  model 
assumes  that  the  loading  of  ASO  is  sequential.  That  is,  the  entire  file  is  loaded,  check- 
summed  and  started  in  one  module  before  the  load  of  the  next  module  commences. 

In  the  ADAS  model  an  effort  was  made  to  balance,  by  size,  the  loading  of  LPUs  into 
the  CPU  modules.  After  CPUll  fails,  the  three  LPUs  originally  loaded  into  CPUll 
are  distributed  over  the  three  remaining  CPU  modules  during  the  reconfiguration 
process.  All  modules,  however,  are  loaded  with  ASO  (80K).  Table  3.1  depicts  the 
allocation  of  LPUs  at  system  startup  while  Table  3.2  depicts  the  allocation  of  LPUs 
following  system  reconfiguration. 

3.1.2.  Node  Name  Conventions 

The  format  for  naming  the  nodes  throughout  the  ADAS  model  is 

NODE_NAME[instance_number] 

where  instance.number  can  range  from  0  to  the  number  of  times  that  the  node  name 
appears  within  a  single  graph  minus  1.  If  a  particular  node  name  appears  only  once 
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Table  3.1.  LPU  Loading  During  Startup 


Module 

LPU  Size 

LPU  Marne 

LPU  Designation 

CPUll 

13K 

Navigation 

LPUl 

CPUll 

13K 

Sensor  Management 

LPU2 

CPUll 

17K 

Display  Generation 
System  (DGS)  Interface 

LPU3 

CPU  12 

80K 

ASl 

Hot  Backup 

n 

21K 

Cockpit  Interface 

LPUl 

mm 

17K 

Guidance 

LPU2 

CPU22 

80K 

ASl 

System  Supervisor 

Table  3.2.  LPU  Loading  Following  Reconfiguration 


Module 

LPU  Size 

LPU  Name 

LPU  Designation 

CPU12 

ASl 

Hot  Backup 

CPU12 

Sensor  Management 

LPUl 

CPU21 

17K 

Guidance 

LPUl 

CPU21 

21K 

Cockpit  Interface 

LPU2 

CPU21 

17K 

Display  Generation 
System  (DGS)  Interface 

LPU3 

CPU22 

80K 

ASl 

System  Supervisor 

CPU22 

1.3K 

Navigation 

LPUl 
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within  a  single  graph,  then  it  will  not  have  an  instance.number  appended  to  it. 

Throughout  the  model  all  primitive  proces.jes  are  consistently  named  to  represent 
the  particular  process  they  are  intended  to  represent.  For  example,  the  node  named 
PIBUS  represents  the  time  and  resources  that  were  utilized  during  actual  transmission 
on  a  Pl-bus.  Where  possible,  nodes  have  been  color-coded  to  indicate  the  type  of 
resource  they  consume. 

In  some  instances  it  is  necessary  to  either  (i)  copy  a  single  token  to  multiple  sink 
nodes  -  in  this  case  a  split  node  is  used,  (ii)  merge  multiple  arcs  into  a  single  arc  -  in 
which  case  a  join  node  is  used,  or  (iii)  delay  the  token  for  a  specific  period  of  time  - 
in  which  case  a  delay  node  is  inserted  between  the  two  primary  nodes. 

Since  split  and  join  nodes  provide  flow  redirection  only,  they  do  not  utilize  resources. 
The  hwjmodule  attributes  for  all  split  and  join  nodes  are  set  to  no,  and  their  fir- 
ing_delay  is  set  to  0.0.  They  do  not  perturb  the  overall  simulation  timing. 

The  delay  nodes  receive  a  specified  fir ing. delay  equed  to  the  delay  between  events  for 
each  event  repetition  they  represent.  For  example,  a  process  that  cycles  at-  8Hz  will 
have  a  delay  representing  the  0.125  seconds  between  consecutive  executions.  It  is 
necessary  that  all  delay  nodes  within  the  model  have  a  resource  available  at  the  time 
the  delay  commences.  For  this  reason,  all  the  delay  nodes  are  assigned  a  dedicated 
hwjmodxile.  These  are  named  delayl  ...  delaya,  where  “n”  is  the  number  of  delay 
nodes  that  appears  throughout  the  entire  ADAS  model.  In  the  simulation  report 
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(sim.out),  all  statistics  gathered  on  the  delayl  ...  delayn  resources  may  be  ignored. 

3.1.3.  Primitive  Hardware  Components 

The  ADAS  model  of  the  AARTS  Demonstration-3  considers  the  modules  listed  in 
Table  3.3  to  be  primitive  hardware  resources.  Their  utilization  is  considered  in  the 
final  simulation  analysis.  This  might  be  called  the  degree  of  granularity  or  resolution 
of  the  ADAS  model.  Since  there  are  two  clusters  in  the  AARTS  Demonstration 
System,  it  is  necessary  to  make  a  distinction  between  the  two.  Therefore,  the  names 
of  all  hardware  modules  incorporate  a  cluster  number  as  well  ais  an  optional  instance 
number,  as  follows: 

hw_module[cluster_number][instance_number] 

Table  3.3  describes  what  each  of  the  hwjmoduhs  used  in  the  ADAS  model  represents. 

3.2.  Hardware  Model 

The  top-level  ADAS  hardware  graph  of  the  AARTS  Demonstration  System  (refer  to 
Figure  A-2)  contains  nodes  representing  the  MAB,  BTB,  M1553B,  Clusterl,  Cluster2, 
System  Mass  Memory,  Pilot  Input,  Sensors  and  Display  Generation  Interface. 

Both  Clusterl  and  Cluster2  are  internal  nodes  and  expand  into  subgraphs.  Figure 
A-3  is  one  of  these  subgraphs.  This  graph  depicts  the  modular  components  of  a 
VAMP.  The  graph  includes  the  five  modules,  the  two  Pl-busses,  eind  the  interfaces 
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to  the  M1553B,  MAB,  and  BTB  busses  (represented  by  graph  in  and  out  ports). 
Each  module  on  this  level  expands  into  a  subgraph.  Figure  A-4  and  Figure  A-5  show 
a  CPU  and  Bus  interface  module  subgraph  respectively.  The  components  in  these 
graphs  are  the  lowest  level  of  resources  used  in  the  ADAS  simulation. 

3.3.  Software  Model 

The  basic  structure  of  the  software  model  is  shown  in  the  top-level  ADAS  software 
graph  of  the  A  ARTS  Demonstration  System  (Figure  A-6).  It  is  comprised  of  five 
major  components:  startup,  normaloperations,  systemessages,  reconfigu¬ 
ration  and  SHUTDOWN.  The  simulated  flow  of  operation  of  the  ADAS  model  is 
STARTUP,  folio-  .e  ’  by  normaloperations.  Upon  the  simulated  failure  of  CPUll, 
RECONFIGURATION  is  simulated  while  non-failed  processes  continue  to  function  in 
the  NORMALOPERATIONS  hierarchy.  This  is  followed  by  a  reconfigured  normal- 
operations.  Finally,  a  Pilot  mode  change  input  triggers  shutdown  of  the  system. 
SYSTEMESSAGES  which  simulates  the  messages  associated  with  management  of  the 
system  commences  as  the  AARTS  software  is  loaded  and  continues  for  the  entire 
operation.  Nodes  sensor  and  pilotinput  are  a  part  of  normaloperations. 

3.3.1.  Startup  Process 

'Fhe  startup  graph,  Figure  A- 7,  is  arranged  in  four  columns  of  nodes  representing 
separate  phases  of  the  startup  and  configuration  process.  Each  column  contains  a 


25 


node  for  each  module  involved  in  the  particular  phase.  The  middle  row  of  nodes 
represents  the  activity  of  the  SMM  during  each  phase  with  cluster  2  and  cluster 
1  activity  being  represented  above  and  below  this  middle  row,  respectively.  For 
example,  referring  left  to  right  in  the  middle  row  of  Figure  A-7,  SMM  will  first  load 
the  ASO  (address  state  0)  software  into  the  BTBs  (node  smmasotobtb),  then  load 
the  ASO  software  into  the  other  cluster  modules,  (smmasocpus).  It  then  loads  the 
ASl  (address  state  1)  software  into  supervisory  modules,  (smmasicpus),  and  finally 
loads  the  LPUs  (loadable  program  units)  into  available  CPUs,  (smmlpuloads).  One 
would  not  normally  represent  this  much  detail  on  a  single  high-level  graph.  In  this 
case,  the  detail  is  included  to  facilitate  model  understanding  and  demonstration. 

All  nodes  on  the  STARTUP  graph  have  subgraphs  except  the  graph  inport  and  out- 
port  nodes,  the  power-on  delay  nodes,  the  surom...x  nodes  for  passively  loaded  mod¬ 
ules,  and  the  endstartup  node.  The  four  phases  of  the  startup  process  represented 
by  the  columns  from  left  to  right  are: 

•  Execution  of  SUROM  (Startup  ROM)  and  BIT  and  active  loading  (loading  over 
the  BTB)  of  the  BTBIM  modules 

•  Passive  loading  (loading  over  the  Pl-bus)  of  the  bootstrap  loader  and  ASO  soft¬ 
ware  into  the  remaining  modules 

•  Arbitration  for  supervisory  roles  and  loading  of  the  ASl  software  into  supervi¬ 
sory  modules 
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•  Loading  of  the  LPUs 


Each  of  these  phases  is  discussed  in  a  separate  section  following  this  introduction. 

3. 3. 1.1.  SUROM  Execution  and  Active  Loading 

The  five  modules  per  cluster  each  load  and  execute  a  startup  ROM  (SUROM)  upon 
power  up.  Upon  completion  of  the  built-in  test  (BIT)  and  sensing  of  the  appropriate 
discrete,  each  module,  except  the  BTBIM’s,  moves  into  the  second  column  (Figure 
A- 7)  where  it  transmits  a  ready  message,  while  waiting  to  be  loaded  with  their  boot¬ 
strap  loader.  For  the  BTBIMs,  after  SUROM  is  executed,  the  module  actively  loads 
the  ASO  software  and  the  Block  Transfer  Bus  (BTB)  driver  software.  They  then 
download  the  LPU  attributes  file.  After  completion  of  the  download,  the  BTBIM 
moves  into  the  second  column  where  it  loads  the  other  modules  in  the  cluster. 

This  process  for  a  Block  Transfer  Bus  Interface  Module  (BTBIM)  is  represented  by 
nodes  surombtBx  in  the  STARTUP  graph.  The  nodes  surombtbx  expand  into 
subgraphs,  which  contain  4  separate  functional  areas  (Figure  A-8): 

•  run  SUROM,  initialize  BTB  interface,  wait  for  token,  and  signal  SMM  that  the 
BTBIM  is  ready  for  loading 

•  receive  the  4-word  response  from  SMM 
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•  receive  the  ASO  from  SMM  in  4K  blocks  and  run  a  checksum  on  it  once  the 
download  has  completed 

•  open,  then  read  the  LPU_ATTRIBUTES  file  from  SMM 

The  ADAS  graph  in  Figure  A-8  shows  that  upon  completion  of  SUROM  tests  (nodes 
STARTSUROM,  SETUPBTBDOWNLOAD  and  BTBBiuo),  the  BTBIM  transmits  a  2- word 
message  (nodes  btb,  xmitready  and  btbiui)  via  the  BTB  to  the  the  System  Mass 
Memory  (SMM)  at  a  lOHz  frequency  (controlled  by  node  delay).  The  BTBIM  receives 
(RCV4WORD  and  BTBBIU2),  a  4- word  message  indicating  the  destination  address,  size, 
expected  checksum,  and  execution  start  address  of  the  BTB  software  that  will  follow 
from  the  SMM.  Following  receipt  of  the  4-word  message,  the  BTBIM  begins  to  receive 
the  ASO  data  in  4K  word  blocks  (represented  by  nodes  rcvaso  and  btbbius).  These 
nodes  will  execute  20  times,  representing  the  receipt  of  twenty  blocks  of  data.  The 
BTBIM  runs  a  checksum  once  ASO  is  loaded  (node  runchecksum)  and  then  proceeds 
to  activate  the  subgraph  of  node  readlpuloc. 

Node  READLPULOC  is  an  interval  node.  The  subgraph  is  shown  in  Figure  A-9.  This 
graph  contains  four  functional  areas: 

•  BTBIM  transmits  open  LPU_ATTRIBUTES  file  request  to  SMM  (nodes  openlpu- 
LOC,  WAIT4TOKENO,  BTBO  and  XMITOPEN) 

•  BTBIM  receives  the  SMM  response,  then  transmits  a  read  request  to  SMM 
(nodes  rcvresponse,  readlpuloc  wait4Tokeni,  btbi  and  xmitread) 
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•  BTBIM  receives  the  LPU_ATTRIBUTES  file  (node  rcvdata) 


•  BTBIM  receives  the  status  of  the  transmission  from  SMM  (node  rcvst^tus) 

3. 3. 1.2.  SMM  Response  During  Active  Load 

The  node  smmasotobtb  in  Figure  A-7  expand?-  '  ”  •  the  subgraph  in  Figure  A-10. 
This  graph  represents  the  SMM  response  to  the  BlBIM’s  transmissions.  The  SMM 
first  loads  the  BTBIM  software  into  BTBIM2,  the  right  half  of  the  graph,  and  then 
into  BTBIMl,  the  left  half  of  the  graph.  In  Figure  A-10,  the  node  -wa  T4TOKen2  rep¬ 
resents  the  token- wait  time  before  SMM  can  transmit  the  4-word  message  to  BTBIM2. 
The  actual  transmission  of  the  4- word  message  is  represented  by  node  xmitdatai. 
The  loop  consisting  of  nodes  wait4TOKEN3,  btbi,  splits  and  deUy  represents  the  token- 
wait  time,  utilization  of  bus  resources,  a  split  to  send  off  tokens  to  different  recipi¬ 
ents,  and  an  interblock  delay  respectively  during  the  twenty  consecutive  4-kilobyte 
data  transmissions  of  ASO  to  BTBIM2.  Node  waiT4Token  delays  while  the  token  is 
received  from  the  preceding  station  on  the  ring.  Since  the  guidance  was  to  assume 
serial  loading  of  the  BTBIMs,  this  delay  represents  the  token  passage  around  the  ring 
to  the  predecessor  node.  Following  completion  of  the  ASO  load  to  BTBIM2,  t  he  SMM 
responds  to  the  open  and  read  LPU_ATTRIBUTES  file  requests  from  BTB1M2.  This 
response  is  simulated  by  the  subgraph  of  node  rdlpuloci,  (Figure  A-11).  The  two 
principal  areas  of  snnn^rdlpuattribs.sxag  are:  receive  the  open  request  and  t  ransmit  a 
response;  receive  a  read  request  and  transmit  the  LPILATTRIBUTES  file.  follow(xI 
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by  a  read  status. 


After  BTBIM2  receives  the  ASO  download,  the  SMM  comnjences  to  load  BTBlMl. 
The  arc  connecting  node  splits  to  wai  'OKENo  in  Figure  A-10  is  used  to  signal  the 
completion  of  the  BTBIM2  load  and  initiate  the  BTBIMl  load. 

3. 3. 1.3.  SUROM  and  Passive  Loading  of  ASO 

The  non-BTBIM  modules,  upon  completion  of  SUROM  tests,  each  transmits  a  2-word 
message  on  the  Pl-bus  at  a  1  Hz  interval.  This  2- word  message  contdins  the  address 
and  module  type.  It  represents  a  repeating  request  to  the  BTBIM  for  a  download  of 
its  bootstrap  loader.  The  SUROM  nodes  for  non-BTBIM  modules  (Figure  A-7)  are 
leaf  nodes  and  are  assigned  a  firing.delay  representing  the  entire  SUROM  processing. 
The  BTBIM  receives  the  2-word  message  on  the  Pl-bus.  It  then  determines  and 
then  transmits  the  correct  4-word  message  to  the  requesting  module.  This  4-word 
message  consists  of  word  count,  data  destination  address,  execution  start  address, 
and  expected  word  count.  The  BTBIM  will  subsequently  broker  the  download  of 
the  bootstrap  loader  from  the  SMM  (via  the  BTB)  to  the  requesting  module  (via  the 
Pl-bus).  Three  separate  ADAS  graphs  hierarchies  are  required  to  depict  the  folio win^: 

•  the  requesting  module’s  activity  during  ASO  load 

•  the  dual  communication  maintained  by  the  BTBIM  -  communicating  with 
SMM,  via  the  BxB,  while  simultaneously  communicating  with  the  requesting 
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module,  via  the  Pl-bus 


•  the  SMM  role  during  the  non-BTBIM  module  load  of  the  bootstrap  loader  and 
ASO 

The  loading  of  the  bootstrap  loader  and  ASO  is  the  same  for  all  non-BTBIM  modules. 
The  loading  of  CPU22  by  BTBIM2  will  be  discussed  in  detail. 

3. 3. 1.4.  CPU  Role  During  Passive  Load 

Figure  A-12  is  the  graph  of  node  AS0CPU22  on  the  startup  graph  (Figure  A-7),  which 
represents  the  requesting  CPU  processes  during  the  passive  loading.  This  graph 
simulates  the  following  functions: 

•  Upon  successful  completion  of  BIT,  the  module  commences  periodic  transmis¬ 
sion  of  the  2-word  message  (left  column) 

•  The  module  then  receives  the  4-word  message  and  sets  up  for  download  (2nd 
column) 

•  After  receipt  of  the  bootstrap  loader,  the  module  opens  the  ASO  file  (3rd  col¬ 
umn) 

•  Upon  receipt  of  the  open  file  response  (node  rcvasoresp),  a  read  request  is 
transmitted.  This  is  followed  by  a  data  block,  (node  rcvasodata)  and  then  a 
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read  status  message  (again  on  node  rcvasoresp)  which  initiates  another  read. 
This  continues  until  the  last  block  of  ASO  is  received. 

•  Upon  receipt  of  the  last  read  status  for  the  ASO  file,  a  checksum  is  run,  (node 
CHECKSUM ASo).  After  a  successful  checksum  the  ASO  software  is  started  (the 
outport  starts  appropriate  system  messages). 

•  After  ASO  is  started,  the  module  opens,  reads,  and  checksums  the  LPU  at¬ 
tributes  file  and  passes  into  the  arbitration  column  of  the  parent  graph. 

3. 3. 1.5.  BTBIM  Role  During  Passive  Load 

Node  AS0BTB2  in  Figure  A-7  is  an  internal  node.  Its  subgraph  (Figure  A- 13)  con¬ 
tains  four  internal  nodes  representing  the  other  four  modules  in  the  cluster.  All  four 
nodes  have  the  same  subgraph  hierarchy.  Each  of  these  nodes  expands  into  the  sub¬ 
graph  shown  in  Figure  A-14.  At  this  level  the  two  distinct  communication  channels 
for  BTBIM2  are  represented  by  internal  nodes  btbtosmmaso  (to  the  SMM),  and 
BTBTOCPUASO  (to  the  CPU). 

Figure  A- 15  is  the  expansion  of  node  btbtosmmaso.  It  represents  the  flow  to  the 
SMM.  There  are  three  processes  represented  on  this  graph. 

•  On  receipt  of  the  two- word  message  from  the  CPU,  the  BTBIM  builds  the 
appropriate  4-word  response  and  transmits  it  to  the  CPU.  Actually,  the  token 
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travels  over  the  arc  between  the  two  nodes  on  the  parent  graph.  Transmission 
to  the  CPU  module  is  represented  in  the  graph  discussed  in  the  next  paragraph. 

•  Along  with  transmission  of  the  4-word  response,  the  BTBIM  transmits  an  open 
file  message  for  the  bootstrap  loader  to  the  SMM.  Upon  receipt  of  the  open  file 
response  from  the  SMM,  the  BTBIM  transmits  a  read  message  to  the  SMM. 
All  subsequent  responses  from  the  SMM  are  acted  on  in  the  subgraph  discussed 
in  the  next  section. 

•  Following  receipt  of  the  bootstrap  loader,  the  CPU  issues  open  and  repeated 
read  commands  to  obtain  its  load.  Forwarding  of  these  commands  to  the  SMM 
is  represented  by  the  left-hand  column  of  the  graph. 

The  subgraph  of  node  btbtocpuas"  (Figure  A-16)  represents  the  following  sequential 
BTBIM  processes. 

•  Once  the  correct  4- word  message  for  the  CPU  heis  been  determined,  the  BTBIM 
transmits  the  message  to  the  CPU  (left  column) 

•  After  the  read  command  has  been  issued  for  the  bootstrap  loader,  the  BTBIM 
receives  the  file  from  the  SMM  and  transmits  it  to  the  CPU  via  the  Pl-bus 
(nodes  rcvboot,  xmitdatao,  ccbexecution2,  pibus2  and  btbpibiU2).  This 
is  followed  by  a  read  status  message  (node  rcvbootresp) 

•  riie  column  headed  by  node  rcvfileresp  represents  the  passage  of  the  open 
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file  response  and  read  status  messages  as  the  CPU  reads  the  ASO  software  in 
4-k  blocks.  The  column  headed  by  node  rcvaso  represents  the  passage  of  the 
data  blocks.  These  two  columns  alternate  as  tokens  are  received  from  memory 
until  ASO  download  is  complete. 

•  When  the  SMM  responds  to  an  open  LPU_ATTRIBUTES  file  request  by  CPU22, 
the  BTBIM  transmits  first  the  response  (node  rcvattribresp)  then  the 
LPU_ATTRIBUTES  file  to  the  CPU  (node  rcvattrib).  Finally,  the  read  status 
is  forwarded,  again  through  node  rcvattribresp. 

3. 3. 1.6.  SMM  Role  During  Passive  Load 

Figure  A-17  is  the  subgraph  of  node  smmasocpus  on  the  startup  graph  (Figure  A-7). 
The  graph  inports  and  outports  represent  tokens  arriving  from  and  passing  to  the 
appropriate  BTBIM.  The  internal  arcs  enforce  the  policy  of  sequential  loading  of  the 
modules.  All  nodes  except  the  first  and  last  on  Figure  A-17  expand  into  the  same 
svibgraph  which  is  shown  in  Figure  A-18. 

On  Figure  A-18,  nodes  inporto  and  outporti  are  the  connections  to  the  preceding  and 
following  nodes  respectively  of  the  parent  graph  (the  internal  arcs  on  that  graph). 
Nodes  inporti  and  outporto  carry  the  tokens  between  the  SMM  and  the  BTBIM.  This 
graph  cotitains  six  primary  functions: 

•  The  left  column  executes  when  the  BTBIM  requests  opening  of  the  bootstrap 
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loader  file.  It  returns  the  open  file  response  to  the  BTBIM. 


•  Upon  receipt  of  the  read  bootstrap  loader  message,  the  second  column  is  exe¬ 
cuted  passing  the  file  followed  by  a  read  status  message. 

•  The  center  column  receives  the  open  file  requests  for  both  the  ASO  and  for  the 
LPU  attributes  file  and  returns  an  open  file  response  (it  is  a  duplicate  of  the 
first  column). 

•  The  reads  for  each  4K  block  of  ASO  enter  the  fourth  column  and  follow  a  path 
over  to  and  through  the  second  column.  This  takes  advantage  of  the  fact  that 
the  bootstrap  loader  is  also  a  4K  block. 

•  The  remainder  of  the  4th  column  is  inactive  in  the  current  simulation.  It  would 
simulate  transfer  of  the  final  short  block  of  a  file  that  does  not  divide  exactly 
into  4K  blocks.  The  additional  column  would  be  needed  to  account  for  the 
different  bus  and  interface  utilization  of  the  shorter  message.  This  column  has 
been  included  in  the  current  model  to  provide  flexibility  and  to  demonstrate 
how  similar  columns  would  be  placed  in  the  BTBIM  and  CPU  portions  of  the 
model  to  simulate  loading  a  file  of  a  different  size. 

•  The  final  column  represents  the  transmission  of  the  LPU_ATTRIBUTES  file 
followed  by  a  read  response.  Again,  it  is  a  duplicate  of  other  columns  except 
for  the  resource  usage  simulated. 
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3. 3. 1.7.  Arbiti-<ii,.on 


The  arbitration  process  follows  completion  of  ASO  loading.  CPU22  is  the  first  CPU  to 
receive  and  execute  the  ASO  software,  and  it  will  (as  the  model  is  currently  configured) 
become  the  system  supervisor  module.  The  subgraph  of  node  arbcpu22  on  (he 
startup  graph  (Figure  A-7)  is  shown  in  Figure  A-19.  All  four  process  nodes  on  this 
graph  have  subgraphs.  Some  will  not  be  described  in  detail.  Figure  A-19  depicts  the 
four  stages  of  arbitration: 

•  Node  ARBCLUSTER  represents  the  issuance  of  five  cluster  supervisor  heartbeats. 
The  feedback  loop  containing  the  delay  controls  the  timing  of  the  heartbeat. 

•  After  “winning”  cluster  supervisor  arbitration  node  loadasi  is  activated.  The 
subgraph  of  this  node  is  similar  to  the  one  for  loading  ASO  (with  the  2-  and  4- 
word  messages,  the  bootstrap  loader,  and  the  loading  of  the  LPU_ATTRIBUTES 
file  deleted).  This  is  supported  by  analogous  BTBIM  and  SMM  hierarchies. 

•  Upon  starting  the  ASl  software,  the  hierarchy  below  node  arbhb  commences 
execution.  The  subgraph  hierarchy  of  this  node  is  similar  to  node  arbcluster 
except  that  heartbeats  are  transmitted  on  the  MAB  and  provision  is  made  to 
stop  the  hot  backup  heartbeat  upon  assumption  of  the  system  supervisor  role 
(the  feedback  loop  from  node  assumesyssup). 

•  After  5  successful  hot  backup  heartbeats,  node  assumesyssup  is  activated  and 
five  system  supervisor  heartbeats  are  issued.  When  this  is  completed,  the  hot 
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backup  heartbeat  is  stopped,  a  token  is  passed  to  the  system  messages  function 
to  commence  the  supervisory  messages,  and  a  token  is  passed  to  node  IPUCPU22 
on  the  startup  graph. 

CPU12,  in  the  meantime,  assumes  the  role  of  cluster  1  supervisor  and  once  it  detects 
the  absence  of  the  hot-backup  pulse,  which  ceased  when  CPU22  became  system  super¬ 
visor,  it  (CPU  12)  assumes  the  role  of  hot-backup.  The  token  passed  on  node  tocpui2 
initiates  hot-backup  arbitration  in  CPU12. 

3. 3. 1.8.  Loading  of  LPUs 

After  completion  of  the  arbitration  process,  the  simulation  proceeds  to  the  loading  of 
the  LPUs,  the  right  hand  column  of  the  startup  graph  (Figure  A-7).  This  is  triggered 
by  the  transmission  of  a  CONFIG_REQUEST  message  by  the  system  supervisor, 
CPU22.  The  individual  cluster  supervisors  relay  the  CONFIGJIEQUEST  to  the 
other  CPUs  within  the  cluster  via  the  Pl-bus.  The  loading  of  individual  LPUs  follows 
in  a  manner  similar  to  the  loading  of  ASO  and  ASl,  with  the  BTBIM  brokering  all 
transfers  from  SMM  to  the  CPU. 

Figure  A-20  is  the  subgraph  of  node  LPUCPU22,  the  system  supervisor  node.  The  left 
two  columns  plus  node  rcvdata  at  the  top  of  column  3  simulate  downloading  the  mis¬ 
sion  database  file.  The  remainder  of  column  3  and  lower  portion  of  column  4  simulate 
the  generation  and  issuance  of  the  configuration  commands.  Node  clusteriactive 


37 


is  the  connection  to  node  cliactive  on  the  parent  graph.  This  connection  prevents 
configuration  from  starting  until  all  modules  have  loaded  and  started  the  A  SO  Soft¬ 
ware.  The  upper  portion  of  column  4  simulates  receipt  of  the  configuration  report  s 
upon  completion  of  the  LPU  loads. 

Node  Pl-busO  through  PI-bus3  all  have  subgraphs  that  look  like  Fh'gure  A-21.  One 
graph  like  that  in  Figure  A-21  has  been  prepared  for  each  pair  of  modules  that  ex¬ 
change  Pl-bus  messages  (the  hardware  modules  on  which  the  nodes  are  to  be  mapped) 
and  for  each  size  of  message  exchanged  (the  amount  of  resource  used).  This  graph  is 
referenced  in  the  node  attribute  subgraphJHename  for  each  exchange  of  a  message  of 
that  size  between  those  two  modules,  and  a  copy  is  incorporated  into  the  flattened 
graph  upon  starting  the  GIPSIM  simulator.  This  ability  to  share  graphs  in  an  ADAS 
model  helps  control  the  size  of  the  model  database.  This  feature  was  seen  earlier 
in  this  report  where  the  same  hierarchy  is  used  four  times  in  the  BTBIM  portion  of 
the  ASO  load  and  the  same  graph  used  six  times  in  the  SMM  portion.  One  could 
employ  a  single  graph  file  like  Figure  A-21  for  all  message  exchanges  and  use  a  script 
file  on  startup  of  the  simulation  (GIPSIM,  CSIM  or  AdaSIM)  to  assign  the  hardware 
mapping  and  firing  delay  for  the  nodes  in  the  various  instances  in  the  model. 

Figure  A-22  shows  a  CPUs  response  to  the  configuration  request  message.  In  this 
case,  two  LPUs  are  loaded  and  a  status  report  is  returned  to  the  cluster  supervisor. 
I'he  CPU  portion  of  the  loading  of  an  LPU  is  represented  by  the  subgraph  of  node 
READiPUi  shown  in  Figure  A-23.  This  is  similar  to  the  loading  of  ASO  shown  in 
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Figure  A- 12  with  the  2-  and  4- word  messages,  the  boot,  and  the  LPU  attributes  file 
deleted.  The  CPU  issues  an  open  file  message,  left  column;  receives  a  response  and 
issues  a  read  (second  column);  and  then  alternates  between  node  rcvdatao  and  the 
second  column  as  the  4K  blocks  are  received.  The  final  short  block  executes  node 
RCVDATAi.  Receipt  of  the  final  read  status  message  initiates  node  runchecksum. 

Figure  A-24  is  the  subgraph  of  node  btb2LPUloads  on  the  startup  graph.  It  contains 
an  internal  node  for  loading  the  mission  database  into  the  system  supervisor  and  one 
for  each  of  the  two  LPUs  to  be  loaded  into  CPU21.  Figure  A-25  is  the  subgraph  of 
node  CP21READ1PU1.  From  left  to  right  the  columns  pass  on  the  CPU  open  and  read 
messages  to  the  SMM,  the  SMM  response  messages  to  the  CPU,  the  4K  data  blocks 
to  the  CPU,  and  the  short  data  block  to  the  CPU. 

Figure  A- 26  is  the  subgraph  of  node  smmlpuloads  on  the  startup  graph.  It  contains 
an  internal  node  for  each  LPU.  For  like  size  LPUs,  a  single  subgraph  file  has  been 
used.  Figure  A-27  is  the  subgraph  of  node  lpuicpu2i.  From  left  to  right  the  columns 
respond  to  the  open  message,  respond  to  the  read  requests  for  4K  blocks,  and  respond 
to  the  read  request  for  the  short  block. 

Figure  A-28  is  the  subgraph  of  node  lpui,dmab2  on  the  startup  graph.  This  graph 
simulates  the  MABIM  in  cluster  2  receiving  the  configuration  request  message  from 
the  system  supervisor  (bottom  of  third  column  in  Figure  A-20),  and  transmitting 
it  to  the  MABIM  in  cluster  1.  The  token  entering  this  graph  on  node  inport  is  the 
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token  that  was  passed  upon  completion  of  the  MABIMs  loading  of  ASO  (see  arc 
on  P'igure  A-7.  The  token  entering  on  node  fromCP22  is  the  one  passed  from  node 
LPUCPU22  to  node  lpulpmab2  on  Figure  A-7.  Node  mab  is  an  internal  node.  Its 
subgraph,  Figure  A-29,  is  similar  to  and  employed  in  the  same  way  as  the  P  1-bus 
subgraph  (Figure  A-21). 

Figure  A-30  is  the  subgraph  of  node  lpuidmabi  on  the  startup  graph.  It  receives 
me  token  from  node  join  in  Figure  A-29  and  transmits  it  on  the  Pl-bus  to  the  cluster 
supervisor  in  cluster  1  (CPU12).  Node  pibus  has  a  subgraph  like  that  in  Figure  .A-21. 

3.3.2.  System  Messages 

Returning  to  the  top  level  graph  (Figure  A-6),  node  systemessages  contains  the 
graphs  that  simulate  the  establishment  of  connections  for  and  passing  of  commands, 
reports,  and  pings  or  pulses  necessary  to  manage  the  system  (except  for  the  actual 
passage  of  configuration  or  shutdown  request  and  report  messages  which  have  been 
modeled  in  these  startup,  reconfigure,  and  shutdown  portions  of  the  model). 

Figure  A-31  is  the  subgraph  of  node  systemessages.  The  eight  nodes  at  the  bottom 
contain  the  activity  of  the  eight  specialist  modules.  These  nodes  are  started  upon 
receipt  of  a  token  on  the  graph  inports  asOstartedx  and  terminate  with  a  token  on  graph 
inport  startrcconflg  (actually  should  be  named  “failure”)  for  node  cpuii  and  fromsimt- 
downx  for  the  others.  The  two  nodes  at  the  top  contain  the  activity  of  the  supervi.sory 
modules.  The  supervisory  module  nodes  have  an  additional  set  of  functions  that  start 
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upon  loading  of  the  ASl  software. 


Figure  A-32  is  the  subgraph  of  node  cpuii  on  the  system  messages  graph.  Upon 
starting  of  the  ASO  software,  various  message  receive  and  transmit  connections  are 
made.  This  is  shown  on  the  upper  portion  of  the  graph.  Upon  completion  of  the 
connection  for  the  ping  message,  the  module  starts  periodic  transmission  of  the  ping 
(I’m  ready)  on  the  Pl-bus.  This  is  simulated  in  the  left  hand  loop  with  a  hierarchy 
below  node  xmitclusping.  When  the  ping  is  acknowledged  by  the  cluster  supervi¬ 
sor  inport  froinCPUi2,  the  ping  is  halted  (a  series  of  inport  tokens  from  node  spUti 
to  node  ORo  “chokes”  the  loop)  and  the  module  pulse  (heartbeat)  is  started.  Inport 
stop  terminates  the  pulse  on  shutdown  in  the  same  way  the  ping  is  terminated.  We 
will  describe  the  simulation  of  the  transmission  (nodes  xmitclusping  and  xmit- 
MODpulsb)  in  the  description  of  the  u/c  transmission  of  supervisor  heartbeats.  One 
additional  feature  of  the  model  is  shown  by  the  two  nodes  below  node  xmitmod- 
PULSE  on  this  graph.  For  messages  that  do  not  elicit  a  response,  the  entire  process, 
including  receipt  of  the  message  by  the  addressee,  is  modeled  in  the  subgraph  of  the 
initiating  process.  This  reduces  the  number  of  arcs  on  the  higher  level  graphs. 

Figure  A-33  is  the  subgraph  of  node  CPU22  in  the  system  messages  graph  (Figure 
A-31).  The  top  portion  is  the  establishment  of  message  connections  upon  starting  the 
ASO  software.  The  initial  pings  and  pulses  for  the  supervisory  module  are  modeled 
in  arbitration  graphs  in  the  startup  hierarchy.  The  bottom  portion  of  the  graph  is 
started  when  the  ASl  software  is  started  in  the  cluster  supervisor.  A  series  of  connec- 
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tions  are  made.  These,  since  they  are  system-wide  connections,  require  transmission 
of  the  channel  array  to  the  MABIM  (nodes  or,  xmitarray  modules  and  mabup. 
datearray).  Node  xmitarray  has  a  subgraph  hierarchy  similar  to  those  shown  in 
Figure  A-28  and  A- 29  with  the  transmission  being  on  the  Pl-bus  rather  than  the 
MAB. 

Node  CLPINGACK  receives  and  acknowledges  the  pings  from  the  other  modules  in  the 
cluster.  Its  subgraph  is  shown  in  Figure  A-34.  Once  the  connections  are  established 
(top  two  nodes),  each  ping  receives  a  response.  This,  it  turns  out,  is  immediate 
for  the  CPU,  MABIM  and  BTBIM  modules  since  they  are  pinging  before  the  ASl 
software  initial  reading  suggests  ASO  is  started  is  started  in  the  cluster  supervisor. 
The  M1553B  module  receives  a  response  to  its  first  ping.  It  does  not  complete  the 
ASO  load  until  after  the  ASl  software  is  started  in  the  supervisor  model.  The  four 
nodes,  pibus2x,  each  have  a  Pl-bus  transmission  subgraph. 

Figure  A-35  is  the  subgraph  of  node  clpuises  on  the  System  supervisor  graph.  This 
figure  combines  the  system  supervisor  (left  column)  and  cluster  supervisor  heartbeats. 
The  loops  are  similar  to  those  for  the  ping  and  pulse  on  the  specialist  node  graph  (Fig¬ 
ure  A-32)  with  the  transmissions  being  stopped  during  shutdown  by  nodes  inporti  and 
splito.  After  the  message  connections  have  been  established,  the  pulse  transmission  is 
commenced. 

I'igure  A-36  is  the  subgraph  of  node  xmitpibclpls.  This  same  graph  (nodes  mapped 
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on  different  hardware)  is  found  below  the  xmit  ping  and  xmit  pulse  nodes  on  the 
specialist  subgraphs.  Node  pibus,  of  course,  has  a  transmission  subgraph.  In  this 
case,  since  there  are  multiple  addressees,  it  is  different  from  the  point-to-point  one. 
This  graph  is  shown  in  Figure  A-37.  Node  xmithsdbclpls  in  Figure  A-35  transmits 
the  pulse  to  the  MABIM.  xmithsdbclpls  has  a  subgraph  like  Figure  A-36  with  the 
Pl-bus  sub-subgraph  shown  in  Figure  A-38.  This  differs  from  Figure  A-21  only  in 
having  a  second  outport  that  feeds  the  loop  for  the  repeated  message.  Node  maB2  on 
Figure  A-35  transmits  the  pulse  to  the  MABIM  in  the  other  cluster.  The  hierarchy 
below  node  mab2  is  the  same  (except  for  a  single  graph  inport)  as  that  shown  for  the 
configuration  request  in  Figures  A-28  and  A-29.  Similarly,  the  hierarchy  below  node 
MABi  which  transmits  the  message  to  CPU12  (the  hot-backup)  is  equivalent  to  that 
shown  in  Figure  A-30  with  a  Pl-bus  transmission  subgraph. 

3.3.3.  Normal  Operations 

During  normal  operations  the  system  messages  and  LPUs  are  running  with  LPUs 
receiving  inputs  from  the  pilot  and  the  sensors.  Figure  A-39  is  a  data  flow  diagram 
of  the  demonstration  three  applications.  Referring  to  the  AARTS  top-level  graph 
(Figure  A-6)  during  normal  operations,  nodes  systemessages,  which  conunenced 
during  startup;  normaloperations,  whose  execution  is  triggered  by  completion  of 
startup;  sensors;  and  pilotinput  are  executing. 

Figure  A-40  is  the  graph  of  node  sensors.  The  simulation  merely  places  the  sens- 
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ings,  AirData  at  5  Hz  and  INSDATA  at  32  Hz,  on  the  MAB.  It  is  pulled  off  at  the 
appropriate  frequency  by  the  appropriate  subgraph  of  node  normaloperations. 
The  graph  port  on  the  left  starts  the  execution  and  that  on  the  right  terminates  it 
upon  shutdown.  The  graph  for  node  piiotinput  is  structured  like  Figure  A-40  with 
the  two  columns  representing  the  transmission  of  the  MMKey  (mission  mode)  and 
the  IMFKey  (multifunction  display).  In  addition,  since  each  input  solicits  a  response 
from  the  cockpit  interface  LPU,  a  graph  outport  is  included  below  each  maBx  node. 

Figure  A-41  is  an  expansion  of  node  normaloperations.  The  left  half  contains 
the  graph  inports  and  nodes  to  distribute  their  tokens-.  The  right  half  contains  two 
columns  of  internal  nodes  and  the  graph  outports.  Upon  completion  of  startup,  a 
token  is  received  on  node  starts  and  distributed  by  node  split  to  the  five  internal 
nodes  in  the  left  column.  These  tokens  start  simulated  execution  of  the  LPUs.  Node 
CPINTERFACE  emits  a  token  to  node  pilotinput  on  the  parent  graph  when  it  has 
established  connections  and  then  receives  inputs  from  pilotinput  through  graph 
ports  MMKey  and  IMFKey.  Similarly,  node  sensormgmto  turns  on  node  sensors. 
When  the  simulated  failure  occurs  a  token  is  received  via  node  failure,  and  node 
biockcpuii  emits  tokens  to  stop  the  processing  in  nodes  navigationo,  sensormgmto, 
and  DGSiNTERFACEn.  After  the  failure  is  detected  and  the  LPUs  have  been  loaded 
into  their  new  CPUs,  nodes  navigationi.  sensormgmti,  and  dgsinterfacei  are 
started  (graph  ports  starto.  i.  and  2).  A  MMKey  input  (mode  change)  into  node 
CPINTERFACE  causes  an  output  on  graph  port  xhutdown  that  triggers  the  shutdown 
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process.  As  LPUs  are  stopped  in  the  shutdown  process,  tokens  are  received  on  nodes 
shutdowno  through  shutdowns  stopping  execution.  The  execution  of  node  cpinterface 
is  stopped  by  stopping  node  pilotinput  on  the  parent  graph. 

Figure  A-42  is  the  subgraph  of  node  cpinterface.  Upon  receipt  of  the  “start”  token 
on  node  inporto,  message  connections  are  established  (left  column).  Node  outporti 
initiates  node  pilotinput  on  the  top-level  graph.  The  LPU  then  responds  to  inputs 
from  the  pilot  (nodes  rcvmmp  and  rcvimfk)  and  waypoint  changes  (node  inporti)  from 
node  GUIDANCE  on  the  parent  graph.  Changes  in  the  variable  “FLYTO”  received  or 
derived  from  pilotinput  are  output  to  node  guidance  on  the  parent  graph  (node 
outporto).  After  an  appropriate  number  of  MMP  inputs,  a  token  is  emitted  on  node 
outports  to  initiate  system  shutdown.  It  can  be  seen  from  this  figure,  and  those  that 
follow,  that  the  focus  of  this  model  is  on  data  transfer  which  is  modeled  in  much 
greater  detail  than  the  CPU  processing. 

Figure  A-43  is  the  subgraph  of  node  sensormgmto.  As  with  cpinterface,  connec¬ 
tions  are  made  first  with  establishment  of  appropriate  connections  enabling  processing 
of  messages.  Outputs  are  provided  to  the  Guidance  LPU  in  CPU21  over  the  MAB 
and  to  the  Display  Generation  System  (DGS)  Interface  and  the  Navigation  LPUs 
internally.  Figure  A-44  is  the  subgraph  of  node  sensormgmti.  After  the  failure, 
this  LPU  is  loaded  into  CPU12,  Navigation  has  been  reloaded  into  CPU22,  and  DGS 
interface  into  CPU21.  As  can  be  seen,  the  changes  from  Figure  A-43  are  primarily  the 
path  for  the  outports.  The  only  other  difference  is  the  deletion  of  the  graph  outport 
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that  turned  the  sensors  on.  Figures  A-45  through  A-47  are  one  version  each  of  tlie 
other  three  LPUs. 

3.3.4.  Failure  and  Reconfiguration 

Figure  A-48  is  the  subgraph  of  node  detect  on  the  top-level  graph  (Figure  A-6). 
This  graph  is  initiated  by  expiration  of  the  firing  delay  of  node  failure  (a  leaf  node) 
on  the  top-level  graph.  Node  detectmisngplse  delays  for  10  pulse  periods  which  is 
the  specified  number  (ref  11)  for  the  cluster  supervisor  to  take  action.  The  remainder 
of  the  graph  represents  the  transmission  of  the  configuration  report  (failure)  message 
from  the  cluster  1  supervisor  to  the  system  supervisor. 

Figure  A-49  is  the  subgraph  of  node  reconfigure  on  the  top-level  graph.  The  upper 
portion  consists  of  nodes  associated  with  preparation  and  transmission  of  the  configu¬ 
ration  requests  messages  necessary  to  load  and  start  the  failed  LPUs  in  new  modules. 
The  last  two  nodes,  other  than  graph  ports,  in  each  column  are  internal  nodes  that 
load  and  start  the  assigned  LPU.  Below  each  ...LOADLPU  node  is  a  subgraph  with 
three  internal  nodes  representing  the  CPU,  BTBIM,  and  SMM  functioning  in  the 
loading  process,  (Figure  A-50).  Below  each  node  in  Figure  A-50  is  a  subgraph  of  the 
form  we  have  seen  in  Figures  A-23,  A-25,  and  A-27.  In  fact,  where  the  module  and 
the  size  of  the  LPU  is  the  same,  the  same  graph  is  used.  The  nodes  ...startlpu  on 
Figure  A-49  have  a  subgraph  that  starts  the  LPU  sending  a  token  into  the  appro¬ 
priate  subgraph  of  NORMALOPS.  They  then  transmit  the  configuration  report  to 
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the  system  supervisor.  Figure  A-51  is  the  subgraph  of  node  cpui2STArti.pu.  This 
configuration  report  must  pass  over  the  MAB  to  cluster  2.  The  other  two  subgraphs 
have  only  the  portion  necessary  to  transmit  the  report  internally. 

3.3.5.  Shutdown 

After  the  reconfigured  system  has  run  for  the  desired  length  of  time,  Shutdown  is 
executed  by  passing  a  token  from  node  xmitmissmode  in  Figure  A-42  through  the 
graph  outport  into  node  shutdown  on  Figure  A-6.  Figure  A-52  is  the  graph  of  node 
SHUTDOWN.  The  timing  can  be  controlled  by  adjusting  the  rate  at  which  MMKey 
tokens  are  passed  to  the  LPU  CPINTERFACE  (currently  set  at  iHz)  and  the  firing 
threshold  attribute  (currently  set  at  5)  on  node  CPt22RcvShutDn  in  Figure  A-52. 

In  order  to  simulate  an  orderly  shutdown  of  the  system,  the  model  forces  a  sequence  on 
the  shutdown  process.  The  module  containing  the  system  supervisor  is  the  last  mod¬ 
ule  to  shut  down.  The  last  module  prior  to  the  system  supervisor  is  the  MABIM  mod¬ 
ule  in  the  cluster  containing  the  system  supervisor.  For  other  clusters,  the  MABIM 
module  is  the  last  and  the  cluster  supervisor  the  next  to  last.  If  we  had  more  than 
two  clusters  we  would  have  assured  that  the  hot-backup  was  the  last  of  the  other 
cluster  supervisors.  In  Figure  A-52  there  are  two  principal  internal  nodes,  one  for  the 
shutdown  of  each  cluster. 

Figure  A-53  is  the  subgraph  of  node  ciu8ter2ShutDn.  Node  CPU22Broadcast  has  a  hier¬ 
archy  l)elow  it  that  passes  the  shutdown  message  token  to  each  of  the  other  modules 
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in  the  cluster.  Node  MAB2PIBU  has  an  inport  that  will  prevent  its  execution  un¬ 
til  the  shutdown  report  is  received  from  cluster  1.  The  system  supervisor,  CPU22, 
shuts  down  after  receiving  the  MAB  shutdown  report.  Each  column  shows  a  module 
first  stopping  and  then  unloading  any  LPUs.  This  is  followed  by  transmission  of  a 
shutdown  report  and  finally  stopping  the  module.  As  LPUs  are  stopped  tokens  are 
output  to  stop  their  execution.  Nodes  outputo  through  4  pass  the  tokens  that  stop 
the  appropriate  sub  hierarchy  in  SYSTEMESSAGES.  As  the  model  is  currently  con¬ 
figured,  the  shutdown  message  to  cluster  1  is  transmitted  after  the  three  modules 
other  than  MAB  and  system  supervisor  in  cluster  2  have  shut  down.  If  we  want 
it  to  be  done  simultaneously,  node  XmitciishutDn  (and  the  hierarchy  below  it  that 
transmits  the  message  on  the  MAB)  would  be  moved  up  to  the  parent  graph.  The 
outports  and  arcs  connecting  the  three  shutdown  report  nodes  with  node  join  would 
be  deleted  as  would  nodes  join  and  ToCiusteri.  On  the  parent  graph  (Figure  A-52)  the 
new  node,  XmitciiShutDn,  would  be  placed  on  the  graph  and  its  inport  connected  to 
an  outport  that  would  be  added  to  node  CPU22ConiputeCnfg.  The  outport  connecting 
node  ciuster2ShutDn  to  node  ciusteriShutDn  would  be  deleted  and  a  new  arc  connecting 
the  outport  of  node  XmitciishutDn  to  that  inport  (of  node  ciusterishutDn)  would  be 
added.  The  subgraph  hierarcliy  would  automatically  follow  with  node  XmitciishutDn 
by  including  the  appropriate  subgraph  filename. 

Figure  A-54  is  the  subgraph  of  node  cpu2istopLPU.  It  contains  a  node  for  each  LPU. 
Figure  A-55  is  the  subgraph  of  one  of  these  nodes.  First,  the  LPU  is  stopped.  This  is 
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followed  by  a  series  of  disconnects  from  the  LPUs  messages  and  finally  an  updating 
of  the  LPU  loaded  and  running  arrays  in  ASO. 

Figure  A-56  is  the  subgraph  of  node  ciusteriShutDn  on  the  shutdown  graph  (Figure 
A-52).  The  shutdown  message  comes  into  node  ac  veil  shutdown  (Figure  A-57)  where 
it  is  transmitted  to  all  modules  on  the  Pl-bus.  This  node  also  collects  the  tokens 
signifying  that  the  M1553BIM,  BTBIM,  and  CPU  have  completed  shutdown  to  trigger 
shutdown  of  the  MABIM.  The  remaining  nodes  function  the  same  as  those  in  cluster 
2  shutdown.  When  all  modules  in  cluster  1  have  completed  shutdown,  node  join  passes 
a  token  back  to  node  ciusteriShutOn  on  the  shutdown  graph  (Figure  A-52)  to  trigger 
execution  of  shutdown  of  the  MABIM  in  that  cluster  followed  by  the  CPU22. 

3.4.  Resource  Utilization 

The  GIPSIM  simulation  tool  simulates  resource  utilization  through  the  node  attribute 
firing.dday  assigned  to  the  leaf  nodes  of  the  model.  When  a  node  is  primed  (all  of 
its  input  conditions  (firing  thresholds)  are  met  and  its  resource  module  available  and 
assigned),  the  assigned  resource  module  becomes  unavailable  for  the  duration  of  the 
assigned  firing  delay  (and  that  period  is  added  to  the  “module  utilization”  collected 
for  output).  Upon  expiration  of  the  firing  delay,  appropriate  tokens  are  placed  in  the 
outport  arc  qtteues  and  the  resource  module  is  released.  Thus,  all  firing  delays  must 
be  calculated  in  common  units.  In  this  case  the  unit  selected  was  microseconds. 
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The  objective  of  this  modeling  effort  is  to  analyze  data  tr«insfer  during  configuration 
and  reconfiguration.  Those  processes  associated  with  data  transfer  are  represented 
with  a  high  degree  of  resolution  and  their  delays  calculated  using  all  available  data  af¬ 
ter  an  exhaustive  search.  Other  processes,  such  as  LPU  functioning  and  configuration 
algorithms,  were  resolved  only  to  the  degree  necessary  to  provide  the  appropriate  pro¬ 
file  of  data  transfer  resource  demands.  This  aggregation  serves  to  reduce  the  running 
time  required  for  analyses. 

This  section  will  describe  the  firing  delays  assigned  in  the  model  and  how  they  were 
calculated. 

3.4.1.  Data  Transmission  Delays 

Data  transmission  delays  depend  upon  the  characteristics  of  the  transmission  system 
and  the  amount  of  data  transmitted.  The  following  paragraphs  address  message  sizes 
and  Pl-bus  and  HSDB  transmission. 

3. 4. 1.1.  Message  Sizes 

Data  transmissions  were  addressed  in  four  categories. 

Those  messages  involved  in  system  management  (transmitted  and  received  by  the 
AARTS  Software)  are  described  in  the  documentation  of  the  system  executive  [11]. 
Table  3.4  contains  a  list  of  these  messages,  their  origin  and  destination,  and  the 
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message  length  in  words. 


Table  3.4.  System  Management  Messages 


STSTEmresSISls 

( Reference  11) 

Sender 

Receiver 

Neme 

Siu 

— 

e  Number 

Bus 

Comment 

ura 

■  .lTTTmTX» 

■  rr  K^PTTir*  ;r  -^mm 

ggHiPPM 

BfiJi 

t;5s 

PI 

iHiH 

tsm 

2.26 

PI 

PVI 

^E.SS 

1 

11 

10,42 

HSDB 

SS  incl  HB 

2000 

14 

13 

42 

15 

13 

HSDB 

BTB 

sflTT 

2 

■  11  1  H 1 M 

"TT - 

Clutter  HeftrtbeAt 

H  :«.«j 

2 

60 

20,25,26 

PI 

2 

20,25,26 

PI 

■•jrrrrwvTT  -tp 

i64.5/lpu 

4'r,42 

SS  incl  HB 

SE.Cluft.^gt 

SE. Kernel 

Cluiter^ing^ck 

2 

61 

37,20 

PI 

SE.Clue_Mgt 

SE.KerneldeSS 

Clu«ter.J*ul«e 

2 

37,20,42 

PlirHSDB 

SS  incl  HB 

SE.ClueJdgt 

DE.ModuleJ^gr 

Cluster^tntu*  Jleq 

2 

6 

37,1,42 

PI 

SE.CluA^gt 

SE.SS 

Clueter^tatuf  Jlpt 

9 

57 

37 

HSDB 

SS  incl  HB 

S£.ClueJ<4gt 

SE.SS 

Syetem^ing 

2 

60 

37,42 

HSDB 

SS  incl  HB 

SE.Clue^gt 

DE.Module^gr 

Clu«terj3onfig^eq 

3+l/lpu 

4.5 

38,1 

PI 

SE.CIusJ«fgt(HB) 

otherClu«.>ilgt 

HB  JIe&rtbe«t 

2 

56 

38,26 

HSDB 

SE.Clue31g((SS) 

SE.HB 

SS^eertbent 

2 

56 

36 

HSDB 

SE.ClueJyfgtfSS) 

otherClus.^Ct 

SS^ing 

2 

60 

38 

HSDB 

SE.SS 

“PVT 

1 

MSM 

SE.SS 

SE.CIu«^gt 

2 

W 

HSDB 

SE.SS 

SE.Clu«..Mgt 

34‘1/lpu 

K 

PI8rHSDB 

SE.SS 

SE.ClueJ^gl 

1 

59 

PI8rHSDB 

SytjQuery 

SE.SS 

SE.HB 

3+8/cl 

56 

BilHi 

HSDB 

Messages  transmitted  to  and  from  the  LPUs  in  the  simulation  were  described  in  data 
provided  by  the  TRW  project  manager  [24].  Table  3.5  describes  these  messages. 

Messages  associated  with  obtaining  files  services  are  documented  in  the  IRS  [8]  [9] 
and  from  data  provided  by  the  TRW  project  manager  [23]  .  Those  employed  in  the 
model  are  listed  in  Table  3.6. 

File  sizes  were  obtained  from  the  TRW  project  in  reference  24  and  through  telephone 
conversations.  The  file  sizes  used  in  the  model  are  shown  in  Table  3.7. 


Table  3.5.  Messages  Transmitted  to  and  from  LPUs 


L] 

1 

MESSAGES 
(Reference  24) 

Sender 

Receiver 

Name 

Size  (words) 

Bus 

SENSORS 

SENSOR  MGT 

Air  Data  Sensor 

4 

MAB 

SENSORS 

SENSOR  MGT 

INS  Sensor 

29 

MAB 

SENSOR  MGT 

DGS  Interface 

Air  Data 

20 

MAB 

SENSOR  MGT 

GUIDANCE 

Air  Data 

20 

MAB 

SENSOR  MGT 

DGS  Interface 

INS  Data 

46 

MAB 

SENSOR  MGT 

GUIDANCE 

INS  Data 

46 

MAB 

SENSOR  MGT 

NAVIGATION 

INS  Data 

46 

MAB 

PILOT 

PVI 

IMFK  Key 

2 

MAB 

PILOT 

PVI 

MMP  Key 

2 

MAB 

PVI 

PILOT 

MMP  Lamp 

1 

MAB 

PVI 

PILOT 

Pilot  Mission  Mode 

1 

MAB 

PVI 

GUIDANCE 

Fly  To 

1 

MAB 

PVI 

PILOT 

IMFK  Command 

32 

MAB 

NAVIGATION 

GUIDANCE 

Sys  Body  Nav  State 

40 

MAB 

NAVIGATION 

DGS  Interface 

Sys  Body  Nav  State 

40 

MAB 

NAVIGATION 

GUIDANCE 

Nav  State 

17 

MAB 

NAVIGATION 

DGS  Interface 

Nav  State 

17 

MAB 

GUIDANCE 

DGS  Interface 

Steering  Control 

18 

MAB 

GUIDANCE 

STORE 

Steering  Control 

18 

BTB 

GUIDANCE 

DGS  Interface 

Steer 

18 

MAB 

GUIDANCE 

PVI 

Guidance  Waypoint 

1  1 

MAB 

DGS  Interface 

M1553B 

Master  Mode  Buffer.l 

32 

M1553B 

DGS  Interface 

M1553B 

Master  Mode  Buffer_2 

32 

M1553B 

DGS  Interface 

M1553B 

Miscellaneous  Msg 

4 

M1553B 
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Table  3.6.  Files  Services  Message  Lengths 


FILES  SERVICES  MESSAGES 
(Reference  8,9,  &  23) 

Service 

Message 

Size  (words) 

Open  File 

3 

Response 

2 

Read  File 

6 

Read  Response 

2 

Table  3.7.  Files  Services  File  Sizes 


FILE  SIZES 
(Reference  24  &  Verbal) 

ASO 

80K  words 

20  blocks 

ASl 

80K  words 

20  blocks 

Cockpit  Interface 

21 K  words 

5  blocks  plus  a  short  block 

DGS  Interface 

17K  words 

4  blocks  plus  a  short  block 

Guidance 

17K  words 

4  blocks  plus  a  short  block 

Sensor  Management 

13K  words 

3  blocks  plus  a  short  block 

Navigation 

13K  words 

3  blocks  plus  a  short  block 

Bootstrap  Loader 

4K  words 

Mission  Control  File 

2K  words 

LPU  Attributes  File 

42K  words 
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3. 4. 1.2.  Pl-bus  Transmission  Delays 


The  following  conditions  and  assumptions  were  used  for  determining  Pl-bus  data 
transmission  rates  for  the  ADAS  model. 

•  Pl-bus  is  a  Type  16  ED  Bus  [1]  (page  B-16) 

•  All  modules  will  vie  for  Pl-bus  before  every  transmission 

•  VIE  sequence  takes  8  bus  cycles  [1]  (page  B-30) 

•  The  HZ  and  DZ  cycles  have  been  included,  implying  non-transfer  wait  cycle 
before  the  Header  and  Data  Acknowledge  cycles  [1]  (Table  5-17,  page  B-71) 

•  Data  will  transfer  from  master  to  slave  without  interruption  provided  the  amount 
of  data  transferred  is  less  than  65,536  words 

•  There  will  be  no  passing  of  Tenure  during  message  passing  or  .\S0  loading  for  all 
the  modules,  and  that  the  absolute  tenure  limit  of  (2^‘’-f  8)  will  not  be  necessary 

•  No  Parameter  Write  type  messages  were  modeled 

•  All  data  transmission  on  the  Pl-bus  shall  use  the  the  Block  Message-SH  se¬ 
quence  [1]  (page  B-69) 

•  The  BTBIM  has  the  highest  priority  (4095)  of  all  modules  connected  to  the 
Pl-bus  [1]  (page  B-110) 
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•  The  Pl-bus  will  have  a  transfer  rate  of  10  million  words  per  second  during  the 
DATA  state,  and  assuming  16  bit  words  only,  and  one  cycle  only  to  transfer 
each  word,  each  cycle  time  is  100  ns,  or  0.1  microseconds 

•  The  Block  Message-SH  Sequence  contains  the  status  words  listed  in  Table  3.8 
for  a  total  overhead  of  8  words  [1]  (page  B-35) 


Table  3.8.  Pl-bus  Status  Words 


Message 

Size  (words) 

HEADER  (HO,  HWA,  HWCO,  HWCl,  HZ) 

5 

HEADER  ACKNOWLEDGE 

1 

DATA  ACKNOWLEDGE  (DZ,  DAO) 

2 

By  including  the  necessary  8  VIE  cycles  and  assuming  1  cycle/ word,  the  total  over¬ 
head  is  16  bus  cycles  per  transmission.  This  coupled  with  the  0.1  microsecond  per 
word  transmission  rate  results  in  the  following  formula: 

Firing  Delay  =  (#words  +  overhead)  x  rate  microseconds 
=  (#words  +  16)  X  0.1  microseconds 

Firing  delays  for  common  message  sizes  are  shown  in  Table  3.9  These  are  the  delays 
placed  on  the  leaf  node  names  pibiu  t  pibus  in  the  transmission  graphs.  It  was 
determined  during  the  modeling  that  the  transfer  rate  between  the  Pl-bus  interface 
unit  and  the  memory  was  slower  than  the  bus  transfer  rate.  This  could  lead  to  loss 
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of  portions  of  messages.  The  modeling  team  was  instructed  to  assume  a  two-channel 
transfer  (2  words  in  parallel)  between  PIBIU  and  memory  and  a  buffer  in  the  PIBIU 
that  would  receive  words  prior  to  transmission  and  collect  them  on  the  receiving  end. 
The  initial  read  was  modeled  along  with  CCB  execution  in  nodes  ccbexecution. 
The  final  writes  were  modeled  along  with  reaction  to  message  labels  in  nodes  Rcvxx 
in  the  model. 

3. 4. 1.3.  High  Speed  Data  Bus  (HSDB)  Transmission  Delays 

'I'he  following  conditions  and  assumptions  were  used  for  the  calculation  of  the  High- 
Speed  Data  Bus  data  transmission  times. 

•  The  Avionics  Bus  Interface  (ABI)  component  of  the  HSDBIM  is  in  the  ACTIVE 
state  following  completion  of  its  SUROM 

•  the  HSDB-ABIs  of  both  clusters  remain  in  the  network.  Ring  admittance  is  not 
modeled 

•  Transmission  Monitor  Timer  (TMT),  Transmission  Streaming  Timer  (TST), 
Initialization  Sequence  Try  Count  (ISTC),  Valid  Message  Transmitted  Count, 
Message  Echo  Error  Count  and  all  “counts”  listed  on  page  114,  [2]  arc  not 
modeled 

•  The  ABI  is  capable  of  transmitting/receiving  on  the  HSDB  while  simultaneously 
transmitting/receiving  to  the  171)0  Module 
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Table  3.9.  PTbus  Firing  Delay 


•  The  ABI  can  fully  enqueue  and  validate  any  message  received  befor*'  transferring 
it  to  the  1750  module 

•  All  transfer  of  data  (HCCB’s,  message  data)  between  the  ABI  and  the  1750 
module  is  via  DMA 

•  All  3  Transmit  Queues  on  the  ABI  can  store  up  to  3839  16-bit  words  each  (one 
buffer  for  each  priority  level)  [2]  (page  103).  Only  priority  1  is  simulated 

•  The  ABI  Receive  Queue  (data  from  HSDB,  enroute  to  1750  module)  can  store 
up  to  8192  16-bit  words  [2]  (page  104) 

•  Block  size  is  256  words  on  the  MAB  and  4K  words  on  the  BTB 

•  The  Bus  transfer  rate  is  50  million  bits  per  second,  or  0.02  microseconds  per 
bit  [2]  (page  59) 

•  The  token  frame  and  preamble  consists  of  40  bits  [2](page  78).  See  Table  3.10. 

•  Message  frame  overhead  is  88  bits  [2](page  78).  See  Table  3.11. 

•  An  intertransmission  gap  of  280  nanoseconds,  [2]  (page  78),  was  used 

•  When  the  Bus  is  idle,  the  token  is  equally  likely  to  be  at  any  point  on  the  ring. 

I'he  assumption  that  the  token  is  equally  likely  to  be  anywhere  on  the  ring  at  any 
time  implies  that  on  the  average  when  a  station  is  ready  to  transmit,  it  will  wait  for 
one  token  passage  (the  average  of  the  token  being  0,  1,  or  2  stations  away).  For  any 
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Table  3.10.  HSDB  Token  Frame 


Parameter 

^Bits 

Preamble 

16 

Start  Delimiter  (SD) 

4 

Bit  4 

1 

Destination  Address  (DA) 

7 

Frame  Check  Sequence  (FCS) 

8 

End  Dehmiter  (ED) 

4 

Table  3.11.  HSDB  Message  Frame  Overhead 


Parameter 

^Bits 

Preamble 

16 

Start  Delimiter  (SD) 

4 

Frame  Control  (FC) 

8 

Source  Address  (SA) 

8 

Destination  Address  (DA) 

16 

Word  Count  (WC) 

16 

Frame  Check  Sequence  (FCS) 

16 

End  Delimiter  (ED) 

4 
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number  of  stations,  n,  on  the  ring,  this  number  would  be  (n-l)/2.  By  not  im])lirit  ly 
modeling  token  passage,  the  output  Bus  utilization  represents  productive  utilization. 
With  token  passing,  including  it  is  always  100%  busy.  Using  this  assumption,  the 
delay  assigned  to  nodes  named  wait4TOKEN  was  calculated  as  the  time  to  pass  a 
token  frame  (and  preamble)  plus  the  intertransmission  gap  or 

40  bits  X  0.02  microsecond/bit  +  0.28  microread  =  1.08  microsecond 

For  the  BIU,  M  AB,  and  BTB  nodes  with  a  message  overhead  of  88  bits,  the  calculation 
is 


(N  X  16  +  88)  X  0.02  microsecond 

where  N  is  the  number  of  words  in  the  message.  Table  3.12  provides  the  HSDB  firing 
delays  for  various  message  lengths. 

3.4.2.  CPU  and  SMM  Delays 

The  firing  delays  assigned  to  nodes  mapped' onto  the  CPU  modules  and  onto  the 
System  Mass  Memory  (SMM)  were  estimated  in  three  different  groups: 

•  SUROM  processing  and  checksums 

•  Message  and  files  services 
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Table  3.12.  HSDB  TIMING 


HSDB 

(microseconds) 

1 

2.08 

2 

2.40 

3 

2.72 

4 

3.04 

6 

3.68 

8 

4.32 

9 

4.64 

17 

7.20 

18 

7.52 

20 

8.16 

22 

8.80 

23 

9.12 

28 

10.72 

29 

10.93 

30 

11.36 

32 

12.00 

40 

14.56 

45 

16.16 

46 

16.48 

55 

19.36 

60 

20.96 

288 

93.92 

520 

168.16 

616 

198.88 

1040 

334.56 

4096 

1312.48 
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•  Other 


Most  key  parameters  used  for  calculating  these  firing  delays  were  provided  by  the 
TRW  project  manager.  Some  of  them  changed  radically  during  the  course  of  the 
modeling  effort.  Those  that  were  originated  with  the  modeling  team  were  submitted 
to  and  either  confirmed  or  corrected  by  the  TRW  project  manager. 


3. 4. 2.1.  SUROM  Processing  and  Checksum  Delays 


The  key  parameters  for  these  calculations  were: 


Memory  access  time 
SUROM  size 
Processor  speed 
Checksum  algorithm 
Memory  test 

Memory  size  M1553B  BIM  Module 
Memory  size  -  other  Modules 
ISA  test  and  discrete  checks 


187.5  nanoseconds 
10,000  words 
2.0  mips 

10  instructions  cycles/word 
4  accesses /word 
128K  words 
256 K  words 

equivalent  to  256 K  memory  test 


Using  these  estimates  one  obtains  the  delays  shown  in  Table  3.13. 


The  checksum  delays  from  Table  3.13  are  used  in  the  appropriate  checksum  nodes 
throughout  the  model.  Since  the  entire  SUROM  process  up  to  transmission  of  the 
ready  message  is  performed  by  the  CPU  without  contention  from  other  processes, 
this  process  is  modeled  in  a  single  leaf  node  with  a  delay  of  339,875  microseconds  for 
the  M1553B  nodes  and  435,875  microseconds  for  all  others. 
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Table  3.13.  Time  for  SUROM  and  Checksum  Events 


FIRING  DELAY  FOR  SUROM  AND  CHECKSUMS 


Read  RAN  to  ROM  Assume  187.5  nanosecond  1  ,875  microsec 

transfer  emd  10,000  word  SUROM. 


Checksum 

Assume  2.0  mips  Processor  ft 

50,000  microsec 

10  instruction  cycles/uord. 

Memory  test 

Assime  4  accesses/uord  ft 

192,000  microsec 

256k  memory 

Memory  test 

Assume  4  accesses/vord  ft 

96,000  microsec 

128k  memory 

Remainder  (ISA  test. 

Assume  equivalent  to 

192,000  microsec 

other  tests.  Discretes) 

memory  test 

Cnecksums 

ASO  80,000  words 

400,000  microsec 

ASl  80,000  words 

400,000  microsec 

Interface  17,000  words 

85,000  microsec 

Cockpit  Interface  21,000  words 

105,000  microsec 

Sensor  Management  13,000  words 

65,000  microsec 

Guidance  17,000  words 

85,000  microsec 

Navigation  13,000  words 

65,000  microsec 

LPU  Attributes  File  42  words 

210  microsec 
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3. 4. 2. 2.  Message  and  File  Services  Delays 


RTI  was  furnished  timing  data  from  the  fifth  AARTS  Quarterly  Review  (QR5)  [22], 
These  data  showed  the  times  in  microseconds  for  execution  of  certain  message  ser¬ 
vices  and  the  goals  that  had  been  specified  for  some  of  them.  In  accordance  with 
instructions  from  the  project  manager,  we  used  the  lessor  of  the  measured  time  or 
the  midpoint  between  the  measured  time  and  the  goal,  whichever  was  less.  These 
times  are  displayed  in  Table  3.14. 

The  numbers  provided  by  QR5  were  for  calls  from  address  states  outside  of  address 
state  0.  They  thus  include  in  and  out  processing  through  an  interface  unit  and  a  BEX 
handler.  Since  some  of  the  system  messages  and  their  connections  originate  within 
address  state  0,  an  estimate  was  needed  for  the  amount  of  time  to  be  ascribed  to  their 
processing.  In  addition,  estimates  were  needed  for  the  files  services  (open,  close,  read, 
write).  A  matrix  of  procedures,  functions,  etc.,  called  by  the  measured  and  unknown 
services  was  constructed.  Table  3.15  contains  this  matrix  at  the  top.  Each  row  of 
the  matrix  describes  a  service.  Each  column  of  the  matrix  describes  a  function  that 
induces  a  delay.  An  x  is  placed  in  the  matrix  if  that  function  is  required  to  perform  the 
service.  The  total  delay  for  a  service  should  equal  the  sum  of  the  delays  for  the  marked 
functions.  The  left  column  of  the  key  defines  the  column  headings  for  the  matrix. 
The  known  (estimated)  times  were  placed  in  the  time  column  and  the  unknown  ones 
(marked  by  asterisks)  were  calculated  using  the  algorithms  and  assumptions  shown 
in  the  lower  right  portion  of  the  table.  The  resulting  times  for  the  .services  provided 
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Table  3.14.  Time  for  Message  I/O  Services 


FIRST  PASS  FIRING  DELAYS  (Used  min(QR5,(QR5+Goal)/2) 


Operation 

Goal 

qR5 

Use 

Connect  Receive 

210 

357 

283 

Redirect 

75 

215 

145 

Flush 

75 

190 

132 

Disconnect  Receive 

210 

223 

217 

Connect  Treinsmit 

210 

382 

296 

Transmit  Novait 

135 

474 

305 

Transmit 

135 

562 

348 

Disconnect  Transmit 

210 

223 

217 

Event  Create 

193 

193 

Event  Set 

225 

103 

103 

Event  Clear 

225 

103 

103 

Event  Toggle 

225 

120 

120 

Event  Polarity. Of 

75 

104 

90 

Event  Is.Created 

101 

101 

Event  Delete 

185 

185 

Semaphore  Create 

191 

191 

Semaphore  Acquire 

105 

104 

104 

Semaphore  Release 

195 

116 

116 

Semaphore  Delete 

177 

177 

Critical  Section  Enter 

135 

96 

96 

Critical  Section  Leave 

135 

96 

96 

Calendar  Seconds  (Clock) 

109 

109 

Simple  Accept 

321 

321 
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within  address  state  0  were  placed  in  the  column  headed  “(ASO).”  The  remark  at 
the  end  of  the  connect  and  disconnect  rows  emphasizes  that  a  transmission  of  the 
channel  array  to  the  HSDBIM  must  be  added  to  each  HSDB  connect  and  disconnect. 
These  are  the  delays  used  in  the  model. 

3. 4. 2. 3.  Other  Delays 

Delays  associated  with  AARTS  algorithms  such  as  processing  the  Mission  Database, 
computing  a  configuration,  stopping  a  CPU,  etc.,  were  estimated  jointly  by  TRW 
and  RTI  personnel.  The  same  was  done  for  the  LPU  algorithms,  the  Bus  Interface 
Module  Software,  and  for  System  Mass  Memory  processing.  These  estimates  are 
displayed  in  Table  3.16.  The  firing  delays  have  all  been  entered  into  the  model  and 
the  script  files  for  setting  firing  delays  with  a  decimal  point  and  two  zeros.  This 
will  facilitate  locating  them  for  change  (in  the  script  files)  should  better  estimates  or 
actual  measurements  become  available. 
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FIRING  DELAYS  FOR  MESSAGE_IO  AND  FILES  SERVICES 


Table  3.15.  Time  for  Message  and  Files  Services 
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Table  3.16.  Assumed  Firing  Delays 


TRANSMIT  TWO  WORD  (XMIT) 

STARTUP.  ARBCPUl  1  (or21).CALLCLUSTERARB 
STARTUP.ARBCPU12  (or22).ARBCLUSTER.CALLCLUSTERARB 
All  MONITORxxHB 
xSMMx.XMITSTATUS 
SMM  send  block 

HSDBIM  process  msg  from  PI  to  BSD  Bus 
HSDBIM  process  msg  from  HSDB 

STARTUP.ARBCPU22.ASSUMESYSSUP.STARTSYSMGMT 

STARTUP.ARBCPU22.ASSUMESYSSUP.STOPHOTHB 

CPU  Process  Mission  Database 

Compute  Configuration /Reconfiguration 

MAB  UPDATE  ARRAY 

All  RCV  system  msg  in  CPU 

DCS  CALCULATE 

CHANGE  WAYPOINT 

COMPUTE  STEER 

COMPUTE  AIRDATA 

COMPUTE  INSDATA 

COMPUTE  MMP 

COMPUTE  IMFK 

COMPUTE  WAYPOINT 

COMPUTE  shutdown,  STOP  CPU,  STOP  LPU 

UNLOAD  LPU  or  ASl 

UPDATE  Structures 


100.00 

100.00 

50.00 

50.00 

348.00 

1000.00 

200.00 

20.00 

400.00 

50.00 

200.00 

600.00 

200.00 

50.00 

300.00 

200.00 

800.00 

600.00 

1800.00 

150.00 

400.00 

500.00 

100.00 

5000.00 

50.00 


68 


3.5.  Flow  Control 


A  GIPSIM  simulation  is  controlled  by  the  passage  of  tokens  between  nodes.  This 
control  is  effected  by  the  assignment  of  values  to  the  attributes  token^consumtjratt, 
token.producejrate,  firing  .threshold^  cind  initialJoken.count  for  node  in  and  outports 
and  to  the  attribute  queue^size  for  arcs.  In  most  cases,  these  attributes  are  set  to  the 
default  value  0  for  initiaLtoken.count  and  1  for  the  others.  The  following  paragraphs 
will  describe  how  these  attributes  are  manipulated  to  control  the  execution  of  the 
model. 

Figure  A-8  is  the  graph  of  node  surombtb2  on  the  startup  graph.  Values  assigned 
for  the  node  in  and  outports  in  this  graph  are  shown  in  Table  3.17. 


Table  3.17.  Port  Attributes  -  Graph  of  Node  SUROMBTB2 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

WAIT4T0KEN 

0 

1 

1 

1 

inport 

RUNCHECKSUM 

0 

20 

20 

0 

inport 

RUNCHECKSUM 

0 

outport 

n/a 

outport 

0 

join2 

0 

2 

2 

0 

inport 

splitl 

0 

25 

25 

24 

inport 

split2 

0 

1 

1 

20 

inport 

split2 

1 

1 

2 

inport 

split2 

0 

outport 

outport 

n/a 

0 

SETUPBTBDOWNLOAD 

0 

outport 

outport 

n/a 

2 

all  others 

all 

1 

1 

0 

inport 

all  others 

all 

outport 

outport 

n/a 

1 

The  graph  commences  execution  when  a  token  is  received  at  expiration  of  the  power- 
up  delay  (through  node  inporto)  on  the  inport  of  node  startsurom.  After  node  start- 
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surom’s  firing  delay  has  passed,  a  token  is  passed  to  node  setupbtbdownload 
(inport  0).  setupbtbdownload  is  an  “or”  node  and  so  will  execute  upon  receipt 
of  this  token.  Two  tokens  produced  by  outport  0  of  node  setupbtbdownload. 
These  provide  for  two  primes  of  inportl  on  node  waiT4TOKEN  (consume  and  thresh¬ 
old  both  1).  The  single  initial  token  on  inportOoi  node  waiT4TOKEN  allows  the  node 
to  execute  upon  receipt  of  the  tokens  from  node  setupbtbdownload.  This  use  of 
an  initial  token  is  the  standard  way  to  initialize  cycles.  After  the  first  transmission  of 
the  2-word  message,  node  delay  waits  for  the  assigned  time  and  then  outputs  a  token 
to  inport  0  of  node  waiT4TOKEN  providing  for  a  second  execution  of  the  message  cy¬ 
cle.  When  node  delay  executes  the  second  time,  both  tokens  have  been  consumed  on 
inportl  of  node  wait4TOKEN  and  the  cycle  of  2- word  messages  terminates.  Node  join2 
connects  to  graph  outport  1  that  represents  the  arc  from  node  surombtbi  to  node 
SMMASOTOBTB  On  the  parent  graph.  Node  joinz  is  an  or  node;  that  is  it  will  execute 
whenever  the  token  threshold  is  met  on  any,  rather  than  all,  of  its  inport  queues. 
The  firing^threshold  and  token.consumejrate  on  inportO  of  node  joinz  has  been  set  for 
execution  after  two  message  transmissions.  Node  spiiti  activates  the  receipt  of  the  4- 
word  message.  It  must  execute  upon  receipt  of  the  first  token  from  the  SMM  and  not 
on  any  of  the  following.  This  is  achieved  by  setting  the  token^consume^rate  and  fir- 
ing_threshold  to  a  number  (in  this  case  25)  greater  than  the  total  number  of  expected 
incoming  tokens  (in  this  case  24)  and  setting  the  initiaLtoken.count  to  one  less.  The 
queue  size  on  the  arc  must  be  set  25  or  more  or  a  full  queue  will  block  the  predecessor 
node.  Node  spiitz  activates  the  receipt  of  a  4K  block  of  data  from  the  SMM  during 
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download  of  the  ASO.  The  feedback  arc  from  outpoito  (zero  token.produce.rate)  to 
inporto  (a  token^consume-rate  and  firing-threshold  of  1  and  initiaLtokeu-count  of  20) 
ensures  that  this  node  will  execute  no  more  than  20  times.  Since  the  sequence  of  4K 
blocks  follows  the  receipt  of  the  4-word  message,  the  firing-threshold  on  inport  1  has 
been  set  to  2  with  a  token-consume-rate  of  1  and  no  initiaLtoken-Count.  This  causes 
node  spiit2  to  commence  execution  upon  receipt  of  the  second  token  from  the  mem¬ 
ory  and  to  continue  to  execute  on  each  succeeding  token  until  the  20  toL-us  initially 
on  inportO  are  consumed.  Again  the  queue  sizes  must  accommodate  the  maximum 
number  of  tokens.  Node  runchecksum  is  set  to  execute  after  receipt  of  twenty  4K 
blocks  of  data  from  the  SMM.  outportl  of  node  runchecksum  would,  if  it  produced 
a  token,  restart  the  entire  process.  Since  the  guidelines  for  the  simulation  was  to 
assume  no  failure  of  BIT  or  checksum,  the  token.produce-rate  has  been  set  to  0. 

Node  READLPULOC  is  an  internal  node.  Therefore,  the  execution  takes  place  in  its  sub¬ 
graph  (Figure  A-9).  The  token-Consume-rate,  firing-threshold,  and  token-prodi  ''e-rate 
attribute  values  are  shown  in  Table  3.18. 


Table  3.18.  Port  Attributes  -  Graph  of  Node  IlEADLPTLOC 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

RCVRESPONSE 

0 

3 

3 

2 

in  port 

RCVDATA 

0 

3 

3 

1 

inport 

RCVSTATUS 

0 

3 

3 

0 

inport 

split 

0 

1 

22 

0 

in  port 

all  others 

all 

1 

1 

0 

in  port 

all  others 

all 

outport 

n/a 

oiitpo. : 

1 

71 


In  this  case,  we  want  nothing  to  happen  until  after  the  4-word  message  and  ASO  have 
been  received  (21  messages).  Thus,  we  put  a  threshold  of  22  on  node  split  which 
receives  the  SMM  inputs.  The  consume  of  1  assures  that  it  will  execute  on  each 
received  message  after  the  21st.  Three  messages  will  be  received  from  the  SMM: 
the  open  file  response,  the  data,  and  the  read  status.  By  putting  a  threshold  and 
consume  of  3  on  the  three  corresponding  nodes  and  initial  token  counts  of  2,  1,  and 
0,  we  achieve  the  proper  sequence  of  execution. 

Figure  A-10  is  the  graph  of  node  smmasotobtb  on  the  startup  graph.  The  to- 
keri-consume.rate,  firing^threshold,  and  tokenjproduce.rate  attribute  values  are  shown 
in  Table  3.19. 


Table  3.19.  Port  Attributes  -  Graph  of  Node  SMMASOTOBTB 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

WAIT4TOKENO 

0 

3 

3 

2 

inport 

WAIT4TOKENO 

1 

20 

20 

0 

inport 

WAIT4TOKEN1 

0 

1 

1 

1 

inport 

WAIT4TOKEN2 

0 

0 

0 

0 

inport 

WAIT4TOKEN2 

1 

3 

3 

2 

inport 

WAIT4TOKEN3 

0 

1 

1 

1 

inport 

XMITDATAO 

0 

outport 

outport 

n/a 

20 

XMITDATAl 

0 

outport 

outport 

n/a 

20 

splitl 

2 

outport 

outport 

n/a 

0 

all  others 

all 

1 

1 

0 

all  others 

all 

outport 

outport 

n/a 

In  this  graph  we  want  the  nodes  wait4TOkeno  and  wait4TOKEN2  to  execute  on 
receipt  of  the  first  message  from  the  appropriate  BTBIM  with  the  4-word  message 
followed  by  the  20  4K  blocks  of  ASO.  The  next  two  messages  are  the  open  and 
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read  for  the  LPU  attributes  file.  They  will  trigger  events  in  the  subgraph  of  node 
RDiPULOCx.  Thus,  we  place  a  threshold  and  consume  of  three  with  an  initial  count 
of  two  on  inports  0  and  1  of  nodes  wait4TOKEno  and  wait4TOKEN2,  respectively. 
The  consume  and  threshold  of  0  on  inport  0  of  node  wait4Token2  allows  the  node 
to  execute  on  inputs  to  inport  1  only.  The  arc  from  node  splits  to  node  wait4Token2 
provides  a  means  to  allow  simultaneous  loading  of  the  BTBIMs  by  putting  a  produce, 
consume,  and  threshold  of  1  on  the  parts  associated  with  this  arc  and  the  arc  from 
node  splits  to  node  wajt4TOKEno  and  an  initial  token  in  the  inport  of  the  node  we 
want  to  “fire.”  First  this  graph  can  be  made  to  transmit  the  4K  blocks  alternately 
to  the  BTBIMs.  As  currently  configured,  the  consume  and  threshold  of  20  on  inport 
1  of  node  wait4TOKeno  prevents  it  from  executing  until  the  BTB2  load  is  complete. 

Nodes  RDLPULOCx  are  internal  nodes  with  graphs  as  shown  in  Figure  A- 1 1 .  The  to- 
ken^consume.rate^  firing.threshold,  and  tokenjproducejrate  attribute  values  are  shown 
in  Table  3.20. 

Table  3.20.  Port  Attributes  -  Graph  of  Node  RDLPULOCx 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

RCVOPENLPULOC 

0 

2 

2 

1 

inport 

RCVRDLPULOC 

0 

2 

2 

0 

inport 

split 

0 

1 

2 

0 

inport 

all  other 

all 

1 

1 

0 

inport 

ali  other 

all 

outport 

outport 

n/a 

1 

For  this  graph  we  have  two  trains  of  events,  each  initiated  by  an  incoming  token. 
Fxociition  must  start  with  the  second  token  re<'eived  from  the  BTBIM  (see  discussion 
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of  Figures  A-8  and  A- 10).  The  threshold  of  2  and  consume  of  1  on  node  split  with 
no  initial  token  assures  that  it  will  execute  on  receipt  of  the  second  incoming  token 
and  any  subsequent  ones.  The  threshold  and  consume  of  2  with  1  initial  token  on 
node  RCVOPENLPULOC  means  it  will  execute  on  receipt  of  the  first  token  from  node 
split  (the  open  request)  and  not  on  the  second.  The  threshold  and  consume  of  2  with 
no  initial  token  on  node  rcvrdlpuloc  means  it  will  execute  on  the  second  token 
received  from  node  split. 

Figure  A- 15  is  the  graph  of  the  BTBIM  receiving  messages  from  a  module  and  passing 
them  to  the  recipient  during  the  loading  of  the  bootstrap  loader  and  ASO  software. 
Table  3.21  shows  the  port  attributes  assigned  to  nodes  in  this  graph. 


Table  3.21.  Port  Attributes  -  Graph  of  Node  BTBTOSMMASO 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

RCV2WORD 

0 

26 

26 

25 

inport 

RCVREADREQ 

0 

1 

2 

0 

inport 

RCVRESPONSE 

0 

50 

50 

49 

inport 

All  Other 

- 

1 

1 

0 

inport 

All  Other 

- 

outport 

outport 

n/a 

1 

We  want  node  rcv2WORD  to  execute  on  the  first  token  received  from  the  module 
and  then  to  ignore  any  others.  We  thus  set  a  consume  and  threshold  greater  than 
the  expected  number  of  incoming  tokens  (26)  and  assigned  one  less  to  the  initial 
token  attribute.  Node  rcvreadreq  must  pass  all  subsequent  tokens  to  the  SMM. 
Therefore,  we  put  on  it  a  consume  of  1  and  a  threshold  of  2  with  no  initial  token. 
Finally,  when  the  memory  responds  to  the  open  request  for  the  bootstrap  loader  (this 
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request  is  initiated  in  this  graph)  this  graph  transmits  a  read  request  to  the  SMM. 
We  want  this  chain  to  execute  on  the  response  to  the  open  file  response  and  not  to 
any  subsequent  SMM  responses.  We  achieve  this  with  a  threshold  and  consume  of  50 
and  an  initial  token  count  of  49. 

Figure  A-16  is  the  graph  of  the  BTBIM  passing  messages  from  the  memory  (and  in  one 
case  from  the  graph  discussed  in  the  preceding  paragraph)  to  a  module.  Table  3.22 
shows  the  port  attributes  assigned  to  nodes  in  this  graph. 


Table  3.22.  Port  Attributes  -  Graph  of  Node  BTBTOCPUASO 


Node 

Port 

Consume 

Threshold 

Initial 

Produce 

Split 

0 

1 

2 

0 

inport 

RCVATTRIBRESP 

0 

2 

44 

0 

inport 

RCVFILERESP 

0 

2 

3 

0 

inport 

RCVFILERESP 

1 

1 

1 

21 

inport 

RCVBOOTRESP 

0 

50 

50 

48 

inport 

RCVBOOT 

0 

50 

50 

49 

inport 

RCVASO 

0 

2 

4 

0 

inport 

RCVASO 

1 

1 

1 

20 

inport 

RCVATTRIB 

0 

45 

45 

0 

inport 

RCVFILERESP 

1 

outport 

outport 

n/a 

0 

RCVASO 

1 

outport 

outport 

n/a 

0 

All  Other 

- 

1 

1 

0 

inport 

All  Other 

- 

outport 

outport 

n/a 

1 

The  first  token  passed  from  the  SMM  hierarchy  into  this  (BTBIM)  hierarchy  is  the 
response  to  the  bootstrap  loader  open  request.  This  triggers  a  read  request  in  the 
graph  discussed  in  the  preceding  paragraph.  The  token  consume  of  1  and  threshold 
of  2  on  node  split  in  this  graph  assures  that  the  first  token  from  SMM  will  be  ignored 
in  this  graph  while  each  succeeding  token  will  cause  an  output.  Commencing  with 
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the  second  incoming  token,  node  split  places  a  single  token  on  each  of  its  outport 
queues  each  time  a  token  is  received  from  memory.  The  first  of  these  tokens  represents 
transmission  of  the  bootstrap  loader.  This  token  causes  node  RCVBoot  to  execute.  The 
consume  of  threshold  of  50  with  an  initial  count  of  49  causes  this  node  to  execute  on 
the  first  token  received  (and,  were  there  to  be  that  many,  on  the  51st).  This  is  followed 
by  a  read  status  message  from  the  SMM  to  the  BTBIM.  Node  rcvbootresp,  with  a 
consume  and  threshold  of  50  and  an  initial  token  count  of  48,  executes  on  the  second 
token  from  node  split.  After  the  bootstrap  loader  has  been  received  by  the  module,  the 
module  transmits  an  open  file  request  for  the  ASO  software.  This  causes  transmission 
of  a  token  representing  the  open  file  response  from  the  SMM.  Node  rcvfileresp  has 
two  inports  and  two  outports.  Inport  O’s  execution  condition  will  be  satisfied  upon 
receipt  of  the  third  token  from  node  split  and  every  second  token  thereafter.  Inport  1 
is  assigned  a  consume  and  threshold  of  1  with  21  initial  tokens  while  outport  1  has  a 
produce  of  zero.  This  means  that  inport  I’s  conditions  will  be  satisfied  21  times  and 
then  it  will  block  further  execution  of  the  node.  Node  rcvaso  is  similarly  configured 
to  receive  20  blocks  of  the  ASO  software  commencing  with  the  fourth  token  from  node 
split.  Thus,  nodes  rcvfileresp  and  rcvaso  alternate  during  the  simulated  download 
of  the  80K  ASO  file  (open  response  followed  by  20  blocks  of  data  each  followed  by 
a  read  status).  Finally,  nodes  rcvattribresp  and  rcvattrib  execute  in  a  similar 
manner  on  the  44th  through  46th  (final)  token  received  from  node  split. 

Other  types  of  employment  of  port  attributes  for  flow  control  can  be  seen  in  the  arbi- 
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tration  graphs.  Figure  A- 12  is  a  graph  of  a  module  receiving  its  bootstrap  loader  and 
ASO  software.  For  CPU  22  (and  12),  the  final  node  to  execute,  node  checksumat- 
TRIB  places  5  tokens  on  the  outgoing  arc  (node  outporti)  that  connects  nodes  AS0CPU22 
and  ARBCPU22  on  the  startup  graph.  Figure  A-58  is  a  subgraph  of  node  ARBCPU22 
where  the  tokens  are  received  by  inport  0  of  node  callclusterarb.  Inport  0  and 
inport  1  of  node  callclusterarb  have  a  consume  and  threshold  of  1  assigned.  In 
addition,  inport  1  has  an  initial  token  to  initiate  the  cycle  through  the  delay  node  on 
the  parent  graph  (Figure  A- 19).  This  provides  for  five  executions  of  this  subgraph. 
Each  execution  places  a  token  on  the  arc  connecting  node  arbcluster  with  node 
LOADASi  on  the  parent  graph  (Figure  A- 19).  The  receiving  node  in  the  graph  of 
node  LOADASI  (Figure  A-59)  is  node  openasi.  The  inport  of  this  node  is  assigned  a 
consume  and  threshold  of  5  assuring  that  the  graph  will  execute  once  after  five  cycles 
through  the  arbcluster  graph.  Port  attributes,  similar  to  those  assigned  for  the 
loading  of  the  ASO  software,  control  the  alternation  between  receiving  responses  (and 
transmitting  reads)  and  receiving  data  in  the  right-hand  portion  of  this  graph.  After 
execution,  node  runchecksum  places  a  token  on  the  arc  connecting  node  loadasi 
to  node  arbhb  on  the  parent  graph.  This  token  causes  a  single  execution  of  node 
MONiTORHB  in  the  subgraph  of  node  aRBHB,  (Figure  A-60).  Node  monitorhb  sends 
a  token  to  node  oro,  which  executes  upon  receipt  of  a  token  on  any  of  its  inports. 
Node  ORO  produces  a  token  that  initiates  the  subgraph  of  node  transmithb.  This 
sul)graph  places  a  token  on  the  outport  connecting  to  node  delay,  which  initiates  subse¬ 
quent  execution.s  of  the  cycle,  and  on  a  graph  port  toASSUMESSYSSUP,  which  connects 
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node  ARBHB  to  node  assumesyssup  on  the  parent  graph.  These  tokens  enter  the 
graph  of  node  assumesyssup.  Figure  A-61,  where  they  enter  the  subgraph  of  node 
ARBSYSSUP,  Figure  A-62,  through  graph  port  start  and  into  node  monitorsshb.  In- 
port  0  of  node  monitorsshb  has  been  assigned  a  threshold  and  consume  of  7  with 
an  initial  token  count  of  2.  This  causes  the  graph  to  initiate  upon  receipt  of  the 
fifth  token  from  the  hot  backup  heartbeat,  and  not  to  initiate  unless  it  receiv^es  seven 
more.  The  module  must  issue  five  non-colliding  system  supervisor  heartbeats  before 
assuming  the  role  of  system  supervisor  and  terminating  the  hot  backup  heartbeat. 
The  number  7  allows  for  six  hot  backup  heartbeats  to  occur  without  reinitiating  the 
graph  during  this  period.  As  it  turns  out,  only  5  occur.  Any  larger  number  could 
have  been  used.  Upon  execution,  node  monitorsshb  places  five  tokens  on  the  arc 
to  node  transmitsshb  which  provides  for  five  executions  of  the  subgraph  of  that 
node  (there  is  an  initial  token  on  the  arc  from  node  delay).  Each  execution  of  this 
subgraph,  in  addition  to  initializing  the  delay,  places  a  token  on  each  of  the  graph 
outports.  These  tokens  are  passed  to  nodes  startsysmgt  and  stophothb  on  the 
parent  graph.  Figure  A-61.  The  inport  for  each  of  these  nodes  is  assigned  a  consume 
and  threshold  of  5;  so,  they  will  execute  after  five  heartbeats.  The  four  graph  out¬ 
ports  connect  to  the  system  messages  function  where  the  supervisor  role  is  initiated 
(including  continuation  of  the  heartbeat);  to  node  LPUCPU22  on  the  startup  graph 
to  allow  starting  of  LPU  loading  (the  out  port  is  misnamed  “tonormalops");  to  the 
ARBHB  node  on  the  parent  graph  to  stop  the  hot  backup  heartbeat;  and  to  CPU12 
to  reinitiate  arbitration  for  hot  backup.  Each  of  these  nodes  passes  a  single  token 
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except  the  one  to  arbhb  which  passes  40  (any  large  number  would  do).  Referring  to 
Figure  A-60,  the  40  incoming  tokens  through  graph  inport  stop  cause  node  oro  to  fire 
repeatedly  (firing  delay  of  zero).  This  results  in  tokens  simultaneously  on  all  arcs  of 
the  cycle  through  node  delay.  Since  the  queue  size  is  1  for  each  of  these  arcs,  none  of 
the  nodes  can  execute.  There  is  no  place  for  an  output  token.  This  stops  the  cycle. 
The  same  approach  is  used  to  stop  heartbeats  and  LPUs  on  simulated  failure  and  on 
shutdown. 

In  the  discussion  of  the  ASO  load,  we  encountered  the  feedback  arc  from  an  outport 
to  an  inport  of  the  same  node  with  a  0  token  produce  and  initial  tokens  sufficient  to 
provide  the  required  number  (and  no  more)  of  executions.  This  method  is  employed 
on  the  top-level  graph  (Figure  A-7)  to  restrict  nodes  powerup  and  failure  to  a 
single  execution.  The  loop  on  node  powerup  appears  redundant  given  those  on  the 
nodes  pwrondlyx  On  the  startup  graph  (Figure  A-7).  When  the  entire  model  is  running, 
either  approach  would  be  sufficient.  However,  if  one  wants  to  run  the  startup  graph 
as  a  model  itself,  the  loops  on  that  graph  are  required.  If  one  wants  to  delete  the 
processing  time  associated  with  simulating  startup  in  order  to  investigate  or  debug 
later  portions  of  the  model,  he  can  change  the  attribute  node^class  of  node  startup 
on  the  top-level  graph  to  leaf.  Then  the  loop  on  node  powerup  is  require*d.  \  similar 
loop  can  be  found  on  node  computenewconfig  in  the  reconfigure  graph  (Figure  A- 
49)  and  on  node  CPU22RcvSiiutDn  in  the  shutdown  graph  (Figure  A-52).  These  allow 
running  these  portions  of  the  model  independently. 
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4.  Results 


In  this  section  we  discuss  model  validation  and  provide  some  simulation  outputs 
that  show  how  the  ADAS  model  can  be  used  to  assess  timing,  performance,  resource 
utilization  and  the  sensitivity  of  these  measures  to  input  parameters. 

The  original  purpose  of  this  model  was  to  calibrate  the  abstraction  against  measure¬ 
ments  of  the  AARTS  demonstration  3  prior  to  expansion  of  the  model  for  analysis 
of  a  full  PAVE  PILLAR  mission  applications  system.  The  AARTS  demonstration 
3  has  been  delayed  so  calibration  has  not  been  conducted.  The  representation  of 
the  modeled  AARTS  and  LPU  functions  h«is  been  validated  through  continuous  in¬ 
terchange  of  model  and  AARTS  design  concepts  throughout  the  project.  In  fact, 
much  of  the  effort  in  constructing  the  model  was  devoted  ‘o  model  changes  reflecting 
design  changes  in  the  ongoing  AARTS  development.  Many  of  these  design  changes 
were  initiated  by  the  discovery,  in  the  modeling  effort,  of  future  problems  should  the 
design  continue  in  its  current  direction  at  that  time.  While  the  functionality  of  the 
model  is  verified,  most  of  the  numbers  assigned  for  resource  utilization  still  rest  upon 
tenuous  estimates.  Before  expanding  the  model,  these  estimates  should  be  replaced 
by  better  estimates  or  by  measured  values.  Following  this,  performance  outputs  such 
as  those  in  the  following  tables  can  then  be  compared  with  actual  performance  and 
any  necessary  changes  made  to  the  model  architecture. 

In  the  remainder  of  this  section,  several  tables  are  displayed  and  discussed.  These  ta- 
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bles  show  resource  utilization  and  timing  of  events  in  simulations  run  with  the  model. 
They  are  discussed  in  the  context  of  how  design  characteristics  input  parameters  or 
modeling  assumptions  impact  the  various  processes.  All  of  the  results  are  extracted 
from  ADAS  outputs.  Table  4.1  shows  the  commencement  and  completion  times  of 
major  stages  of  the  basic  model. 


Table  4.1.  ADAS  Model;  Subprocess  Timing 


Sub- Process 

Name 

Simulation  time 
Commencement  (/xs) 

Simulation  time 
Completion  (ps) 

Comments 

Startup 

5177719 

Up  through  loading  of  LPUs 

Normalops_l  OPS 

5174636 

6650000 

Until  CPU  11  fails 

Reconfiguration 

6650000 

8017927 

Reallocation  of  LPUs 

Normalops_2 

8017927 

9183419 

CPU  11  now  off-line 

Shutdown 

9183419 

9296302 

CPU22  last  to  shut  down 

Table  4.2  displays  the  completion  time  of  key  events  during  system  startup.  This  (ta¬ 
ble)  focuses  upon  the  loading  of  the  ASO  software  into  modules,  the  loading  of  ASl 
software  into  supervisory  modules,  and  the  loading  of  LPUs  into  the  CPUs.  These 
activities  terminate  with  the  completion  of  the  checksum  on  the  download.  The 
current  model  configuration  requires  completion  of  the  download  of  the  bootstrap 
loader,  the  ASO  software  (including  checksum),  and  the  LPU  attributes  file  into  one 
module  before  loading  of  the  next  module  commences.  The  ASl  software  is  loaded 
into  supervisory  modules  when  they  are  ready  without  such  a  restriction.  The  only 
constraint  in  the  loading  of  ASl  software  is  contention  with  ongoing  ASO  loads  for 
shared  resources.  LPU  loading  (including  the  mission  database  file  into  supervisory 
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Table  4.2.  Startup  with  Assigned  Delays 


TIME 

(microsec) 

HARDWARE 

MODULE 

EVENT 

1449514 

MAB2CPU 

STARTUP:AS0MAB2:CHECKSUMAS0 

1936773 

MABICPU 

STARTUP:AS0MAB1:CHECKSUMAS0 

2424031 

CPU22CPU 

STARTUP:AS0CPU22:CHECKSUMAS0 

2911896 

CPU12CPU 

STARTUP:AS0CPU12:CHECKSUMAS0 

3419078 

CPU21CPU 

STARTUP:AS0CPU21  rCHECKSUM  ASO 

3449520 

CPU22CPU 

STARTUP;ARBCPU22:L0ADAS1:RUNCHECKSUM 

3931165 

CPUllCPU 

STARTUP:AS0CPU11:CHECKSUMAS0 

3948036 

CPU12CPU 

STARTUP:ARBCPU12:L0ADAS1;RUNCHECKSUM 

4418746 

M1553B2CPU 

STARTUP:AS01553B2:CHECKSUMAS0 

4908187 

M1553B1CPU 

STARTUP:AS01553B1:CHECKSUMAS0 

5017493 

CPUllCPU 

STARTUP:LPUCPU1 1  :readlpul:RUNCHECKSUM 

5039873 

CPU21CPU 

STARTUP:LPUCPU21:readipul;RUNCHECKSUM 

5097436 

CPUllCPU 

STARTUP:LPUCPUll:readlpu2:RUNCHECKSUM 

5142472 

CPU21CPU 

STARTUP:LPUCPU21:readlpu2:RUNCHECKSUM 

5176190 

CPUllCPU 

STARTUP:LPUCPUll:readlpu3:RUNCHECKSUM 

5177719 

na 

STARTUP:ENDSTARTUP 

modules)  commences  only  after  all  modules  have  completed  the  ASO  download.  The 
LPUs  are  loaded  sequentially  in  an  individual  CPU.  Separate  CPUs  contend  for  re¬ 
sources  during  LPU  loading.  It  can  be  seen  from  Table  4.2  that  the  ASO  download 
for  a  module  takes  0.49  seconds  (rounded),  with  those  conducted  concurrent  with 
ASl  downloads  (CPU21  and  CPUll)  taking  0.51  seconds  due  to  resource  contention. 
The  delay  for  checksum  of  the  80k  file  is  0.4  seconds  and  the  bus  transfer  time  for 
82k  words  is  0.036  seconds.  This  means  that  0.054  seconds  of  delay  are  attributed 
to  the  functioning  of  the  BTBIM,  o*4M,  CPU  (open  and  read  command,  etc.),  and 
read  status  reporting.  The  remainder  of  the  table  shows  the  interleaving  of  the  LPU 
reads. 
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Table  4.3.  Failure  and  Reconfiguration  with  Assigned  Delays 


TIME 

(microsec) 

HARDWARE 

MODULE 

EVENT 

6650000 

7900000 

7901450 

7997302 

7997679 

8017927 

failure 

detect 

CPU22CPU 

CPU12CPU 

CPU22CPU 

CPU21CPU 

FAILURE 

DETECT-.DETECTMISNGPLSE 

RECONFIGURErCOMPUTNEWCONFIG 

CP12LOADLPU:CPU12LOADLPU:RUNCHECKSUM 

CP22LOADLPU:CP22LOADLPU:RUNCHECKSUM 

CP21LOADLPU:CPU21LOADLPU:RUNCHECKSUM 

Table  4.3  shows  similar  data  for  the  period  from  the  simulated  failure  of  CPUll 
through  the  reloading  of  the  LPUs  into  other  CPU  modules.  As  can  be  seen,  the 
time  to  react  to  a  failure  is  dominated  by  the  time  to  detect  the  failure  (10  missed 
pulses  at  8Hz  =  1.25  seconds).  From  detection  of  the  failure  through  reloading  and 
checksum  of  all  three  LPUs  took  0.12  seconds. 

Table  4.4  shows  the  sequence  of  events  during  shutdown.  The  events,  STOPx,  are 
the  final  stopping  of  the  indicated  module.  The  shutdown  process  took  just  over  0.11 
seconds.  Also  shown  are  the  time  f  completion  of  each  LPU  unload.  The  model,  as 
currently  configured,  assumes  that  all  LPUs  are  stopped  before  unloading  commences. 

Table  4.5  shows  resource  utilization  during  selected  time  periods.  The  utilization  of 
bus  interface  units  and  the  MI553B  module  was  much  smaller  than  that  of  the  modules 
displayed  in  Table  4.5  and  is  not  shown  in  order  to  reduce  the  size  of  the  table.  This 
table  shows  that  startup  through  arbitration  utilizes  the  specialist  and  MAB  CPUs 
19%.  The  BTBCPUs  have  a  slightly  higher  utilization  as  they  broker  the  downloads, 
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Table  4.4.  Shutdown  with  Assigned  Delays 


TIME 

(microsec) 

HARDWARE 

MODULE 

EVENT 

9183419 

Token  received  to  start  shutdown 

9184235 

M1553B2CPU 

Cluster2ShutDn:STOPO 

9184237 

BTB2CPU 

Cluster2ShutDn :  STO  P 1 

9215986 

CPU21CPU 

Cluster2ShutDn:CPU21UnloadLPU;UnloadLPUl 

9221086 

CPU21CPU 

Cluster2ShutDn:CPU21UnloadLPU:UnloadLPU2 

9226086 

CPU21CPU 

Cluster2ShutDn:CPU2lUnloadLPU:UnloadLPU3 

9226700 

CPU21CPU 

CIuster2ShutDn:STOP2 

9228205 

M1553B1CPU 

ClusterlShutDn:STOP0 

9228207 

BTLUCPU 

ClusterlShutDn:STOPl 

9255165 

CPU12CPU 

ClusterlShutDn:CPU12UnloadLPU:UnloadLPUl 

9260165 

CPU12CPU 

ClusterlShutDn:CPUl2UnloadLPU:UnloadASl 

9260979 

CPU12CPU 

ClusterlShutDn:STOP2 

9261865 

MABICPU 

ClusterlShutDn:STOP3 

9262532 

MAB2CPU 

Cluster2ShutDn:STOP3 

9291252 

CPU22CPU 

Cluster2ShutDn:CPU22UnloadLPU:UnIoadLPUl 

9296252 

CPU22CPU 

Cluster2ShutDn;CPU22UnloadLPU:UnloadASl 

9296302 

CPU22CPU 

Cluster2Sh-tDn:STOP4 
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Table  4.5.  Resource  Utilization  (Standard  Delays) 


Start  Thru 
Arbitration 

LPU 

Loading 

Initial 

LPU 

Loading 

Reconfigure 

Time  Increment 

4.451177 

0.723211 

0.115461 

BTBICPU 

21% 

3% 

3% 

BTB2CPU 

21% 

1% 

6% 

CPUllCPU 

19% 

31% 

0% 

CPU12CPU 

28% 

2% 

64% 

CPU21CPU 

19% 

27% 

78% 

CPU22CPU 

28% 

3% 

62% 

MABICPU 

19% 

1% 

2% 

MAB2CPU 

19% 

2% 

2% 

BTB 

7% 

7% 

12% 

MAB 

0% 

0% 

0% 

PIBUSl 

1% 

1% 

1% 

PIBUS2 

1% 

1% 

3% 

SMM 

11% 

11% 

16% 

The  supervisory  modules,  CPU12  and  CPU22,  show  the  highest  CPU  utilization  since 
they  must  download  the  ASl  software.  The  utilization  of  the  buses  is  small.  During 
the  LPU  loading,  CPUll  (3  LPUs)  and  CPU21  (2  LPUs)  are  significantly  busy.  The 
low  utilization  of  the  BTBCPUs  and  the  BTB  reflect  the  fact  that  as  many  as  3  LPUs 
are  serially  loaded  into  a  single  CPU  with  a  large  checksum  delay  between  them.  The 
final  colunm  shows  the  utilization  during  the  reconfiguration.  LPU21  has  two  LPUs 
continuing  to  operate  during  this  period.  A  higher  BTBCPU  and  BTB  utilization  is 
achieved  since  toads  and  checksums  can  be  achieved  in  parallel  (1  LPU  was  loaded 
into  each  of  the  three  remaining  CPU  modules). 


As  stated  before,  the  only  “measured”  data  specific  to  AARTS  that  was  available  was 


the  simulation  results  for  message  10  functions  presented  in  quarterly  review  number 
5  (QR5).  For  the  model,  we  used  the  mid-point  between  these  numbers  and  the  goals 
specified  for  these  services.  We  ran  a  simulation  using  the  actual  QR5  numbers  for 
comparison.  The  method  for  estimating  numbers  for  unknown  message  10  and  files 
services  used  for  this  effort  was  the  same  as  used  for  the  basic  model.  Table  4.6, 
a  duplicate  of  Table  3.15  except  for  the  numbers,  shows  the  new  calculations  and 
results.  Tables  4.7,  4.8,  and  4.9  show  the  timing  with  these  numbers  for  the  same 
events  as  those  shown  in  Tables  4.2,  4.3,  and  4.4.  We  see  that  a  large  increase 
in  the  CPU  times  required  for  files  services  had  only  a  small  effect  on  the  startup 
times,  about  a  3%  increase.  Startup  time  is  dominated  by  the  checksums.  The  effect 
during  reconfiguration  was  about  twice  as  large  (6%),  while  that  during  shutdown 
(mostly  message  oriented)  was  8%.  Table  4.10  shows  resource  utilization  using  the 
QR5  delays.  This  table  can  be  compared  with  Table  4.5.  As  can  be  seen,  the  larger 
messages  and  files  services  times  had  little  effect  on  resource  utihzation. 

Finally,  runs  were  conducted  using  the  two  sets  of  firing  delays  during  a  period  of 
normal  operations.  Each  period  commenced  with  the  completion  of  the  startup  and 
configuration  processes.  Each  was  run  for  an  identical  simulated  time  period.  All  LPU 
outputs  fired  the  same  number  of  times  during  the  time  period  for  each  set  of  firing 
delays.  Table  4.11  shows  the  utilization  of  the  CPUs  during  this  time  period.  The 
impact  of  the  increased  message  passing  time,  while  small,  is  more  pronounced  during 
normal  operations  than  during  the  file  loading  periods  where  checksums  dominate. 
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FIRING  DELAYS  FOR  MESSAGE^IO  AND  FILES  SERVICES 
(using  QR5  numbers) 


Table  4.6.  Time  for  Message  and  Files  Services  (QR5  Numbers) 
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Table  4.7.  Startup  with  QR5  Delays 


HARDWARE 

MODULE 

EVENT 

1466686 

MAB2CPU 

STARTUP:AS0MAB2:CHECKSUMAS0 

1972272 

MABICPU 

STARTUP:AS0MAB1:CHECKSUMAS0 

2477519 

CPU22CPU 

STARTUP:AS0CPU22:CHECKSUMAS0 

2982934 

CPU12CPU 

STARTUP:AS0CPU12:CHECKSUMAS0 

3509585 

CPU21CPU 

STARTUP:AS0CPU21:CHECKSUMAS0 

3532701 

CPU22CPU 

STARTUP:ARBCPU22:L0ADAS1:RUNCHECKSUM 

4034098 

CPUllCPU 

STARTUPrASOCPUl  IrCHECKSUMASO 

4036766 

CPU12CPU 

STARTUP:ARBCPU12:LOADASl:RUNCHECKSUM 

4539370 

M1553B2CPU 

STARTUP:AS01553B2;CHECKSUMAS0 

5045518 

M1553B1CPU 

STARTUP:AS01553B1:CHECKSUMAS0 

5167280 

CPUllCPU 

STARTUP:LPUCPU1 1  :readlpul  :RUNCHECKSUM 

5185394 

CPU21CPU 

STARTUP:LPUCPU21:readlpul:RUNCHECKSUM 

5249141 

CPUllCPU 

STARTUP:LPUCPUll:readlpu2:RUNCHECKSUM 

5291346 

CPU21CPU 

STARTUP:LPUCPU21:readlpu2;RUNCHECKSUM 

5330662 

CPUllCPU 

STARTUP:LPUCPUll:readlpu3:RUNCHECKSUM 

5332659 

na 

STARTUP:ENDSTARTUP 

Table  4.8.  Failure  and  Reconfiguration  with  QR5  Delays 


TIME 

(inicrosec) 

HARDWARE 

MODULE 

EVENT 

6650000 

7900000 

7901450 

7993796 

7999823 

8023243 

failure 

detect 

CPU22CPU 

CPU12CPU 

CPU22CPU 

CPU21CPU 

FAILURE 

DETECT:DETECTMISNGPLSE 

RECONFIGURE:COMPUTNEWCONFIG 

CP12LOADLPU:CPU12LOADLPU:RUNCHECKSUM 

CP22LOADLPU;CP22LOADLPU;RUNCHECKSUM 

CP21L0ADLPU:CPU21L0ADLPU:RUNCHECKSUM 
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Table  4.9.  Shutdown  with  QR5  Delays 


TIME 

(microsec) 

HARDWARE 

MODULE 

EVENT 

9339641 

Token  received  to  start  shutdown 

9340458 

M1553B2CPU 

Cluster2ShutDn :  STO  PO 

9340460 

BTB2CPU 

Cluster2ShutDn :  STOP  1 

9374756 

CPU21CPU 

Cluster2ShutDn:CPU21UnloadLPU:UnloadLPUl 

9379756 

CPU21CPU 

Cluster2ShutDn:CPU21UnloadLPU:UnloadLPU2 

9384756 

CPU21CPU 

Cluster2ShutDn;CPU21UnloadLPU:UnloadLPU3 

9385721 

CPU21CPU 

Cluster2ShutDn:STOP2 

9387507 

M1553B1CPU 

ClusterlShutDnrSTOPO 

9387509 

BTBICPU 

ClusterlShutDnrSTOPl 

9414417 

CPU12CPU 

ClusterlShutDn:CPU12UnloadLPU:UnloadLPUl 

9419417 

CPU12CPU 

ClusterlShutDn:CPU12UnloadLPU:UnloadASl 

9420081 

CPU12CPU 

ClusterlShutDn:STOP2 

9420968 

MABICPU 

CIusterlShutDn:STOP3 

9421635 

MAB2CPU 

Cluster2ShutDn :  STOP3 

9450354 

CPU22CPU 

Cluster2ShutDn:CPU22UnloadLPU:UnloadLPUl 

9455354 

CPU22CPU 

CIuster2ShutDn:CPU22UnloadLPU:UnloadASl 

9455404 

CPU22CPU 

Cluster2ShutDn:STOP4 

89 


Table  4.10.  Resource  Utilizatir.n  (QR5  Delays) 

Start  Thru  LPU  LPU 

Arbitration  Loading  Loading 


Initial  |  Reconfigure 


Time  Increment 

4.509041 

0.792022 

0.116594 

BTBICPU 

21% 

4% 

5% 

BTB2CPU 

21% 

2% 

7% 

CPUllCPU 

19% 

30% 

0% 

CPU12CPU 

28% 

3% 

66% 

CPU21CPU 

19% 

27% 

79% 

CPU22CPU 

28% 

4% 

63% 

MABICPU 

19% 

1% 

2% 

MAB2CPU 

19% 

2% 

2% 

BTB 

6% 

7% 

12% 

MAB 

0% 

0% 

0% 

PIBUSl 

1% 

1% 

1% 

PIBUS2 

1%  • 

1% 

3% 

i  SMM 

11% 

11% 

16% 

Table  4.11.  Resource  Utilization  During  Normal  Operations 


Modulo 

Standard 

Delay 

QR5 

Delay 

CPUllCPU  (3  LPUs) 

16% 

19% 

CPU12CPU  (Hot  Backup) 

1%  • 

2% 

CPU21CPU  (2  LPUs) 

9% 

12% 

CPU22CPU  (Sys  Supervisor) 

2% 

2% 
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5.  Model  Modification  or  Expansion 


The  details  presented  in  Sections  3.3,  3.4,  and  3.5  are  intended  to  provide  the  user 
with  sufficient  understanding  of  the  model  and  modehng  assumptions  to  be  able  to 
modify  the  model  to  accommodate  different  assumptions  or  expand  it  for  a  broader 
scenario.  Some  modifications  might  include  any  or  all  of: 

-  Expansion  to  more  or  larger  clusters 

-  Expansion  to  a  larger  number  of  LPUs 

-  Larger  and/or  more  complex  LPUs 

-  Different  file  access  routes,  i.e.,  memory  modules  in  clusters 

-  Different  failure  patterns 

This  section  presents  further  elaboration  on  model  expansion  and  modification. 

Figure  A-63  is  a  top-level  graph  for  a  4  cluster  configuration.  No  change  has  been 
made  in  the  LPU,  failure  and  reconfigure  portions  from  the  graph  in  Figure  A-6.  The 
only  changes  on  this  graph  are  an  increased  number  of  arcs  from  nodes  startup  and 
SHUTDOWN  to  node  systemessages  and  a  reduction  in  the  number  of  arcs  from 
node  POWERUP  to  node  startup. 

Earlier,  in  the  discussion  of  the  startup  graph,  (Figure  A-7)  we  stated  that  the  graph 
contained  more  detail  than  is  normal.  For  this  4-cluster  model  we  incorporate  the 
same  functionality  into  a  hierarchical  expansion.  Figure  A-64  is  a  first-level  startup 
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graph  for  the  4-cluster  model.  As  can  be  seen,  this  graph  shows  each  cluster  receiving 
a  “powerup”  input  and  outputting  the  tokens  to  initiate  the  system  messages  for  the 
cluster  modules.  The  node  endstartup,  as  in  the  basic  model,  receives  a  token  from 
each  cluster  indicating  completion  of  configuration  and  outputs  a  token  to  initiate 
normal  operations.  This  node  has  0  delay  and  consumes  no  resources.  In  addition, 
each  cluster  not  containing  the  system  supervisor  transmits  a  token  to  the  system 
supervisor  cluster,  node  clusters,  to  signify  completion  of  arbitration  and  ready  for 
configuration. 

Figure  A-65  shows  the  subgraph  of  node  clusters.  Here  we  see  the  4  primary 
phases  of  startup  represented  separately.  Nodes  surom,  loadaso,  arbitration, 
and  CONFIGURE  represent  the  cluster  functioning  during  the  respective  phases.  Each 
“phase”  node  is  connected  to  a  node  representing  the  memory  functions  during  that 
phase  (nodes  loadasotobtb,  loadasotomodules,  loadasitocpu,  loadlpus). 
Each  of  the  memory  function  nodes  would  contain  one-half  of  the  hierarchy  below 
the  equivalent  memory  function  node  on  the  basic  startup  graph.  For  instance,  node 
LOADASOTOMODULES  would  have  a  subgraph  that  consists  of  one  row  of  internal  nodes 
and  their  inport  and  outport  nodes  from  Figure  A- 17.  The  subgraph  for  the  internal 
nodes  of  these  “half  graphs”  would  be  the  same  graph  used  in  the  basic  model. 

For  the  current  PAVE  PILLAR  concept,  all  memory  functions  are  mapped  onto  a 
central  system  mass  memory.  For  a  concept  with  a  memory  module  in  each  cluster, 
the  memory  function  nodes  would  be  mapped  onto  the  separate  memory  module 
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in  the  cluster  and  the  arcs  between  cluster  functions  and  memory  functions  would 
represent  Pl-bus  instead  of  HSDB  transfers.  In  this  case,  if  the  cluster  memory  is 
volatile,  we  would  need  a  graph  inport  to  a  memory  node  coming  from  the  SMM 
(which  would  be  represented  on  the  parent  or  a  higher  level  graph)  for  loading  the 
cluster  modules.  Looking  again  at  Figure  A-65  as  a  whole,  we  can  see  that  the  BTB 
actively  loads  the  ASO  software  in  the  suaoM  node  and  outputs  a  token  to  initiate  its 
system  messages.  All  modules  output  tokens  to  initiate  the  ASO  passive  loads.  Passive 
loading,  node  LOADASO,  outputs  tokens  as  modules  start  the  ASO  software  to  initiate 
the  appropriate  system  messages.  In  addition,  the  CPUs  output  initiation  tokens 
to  the  arbitration  process  and  the  MAB  signifies  “ready”  for  configuration.  Upon 
completion  of  arbitration,  the  system  supervisor  (or  Hotbackup  or  cluster  supervisor) 
outputs  a  token  to  initiate  supervisory  messages  and  the  CPUs  signify  “ready”  for 
configuration.  In  the  other  clusters,  the  cluster  supervisor  signifies  “ready”  to  cluster 
3.  These  are  the  three  external  inputs  to  node  configure.  When  the  configuration 
is  completed  a  token  is  output  to  node  endstartup  on  the  parent  graph. 

Two  nodes  on  Figure  A-65  have  been  expanded  to  show  the  connection  to  the  graphs 
in  the  basic  model.  Figure  A-66  is  the  subgraph  of  node  surom  on  Figure  A-65.  It 
is  readily  seen  that  this  graph  is  the  upper  left  corner  of  the  original  startup  graph 
(Figure  A-7).  Outports  have  been  added  for  the  connection  to  the  memory  function 
and  to  the  load  ASO  function.  From  this  point  downward,  the  graphs  from  the  original 
model  are  used.  Figure  A-67  is  the  subgraph  of  node  tOADASo  in  Figure  A-65.  This 
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graph  is  cut  from  the  upper  portion  of  the  second  column  of  Figure  A-7.  Graph  in 
and  outports  have  been  added  for  the  connections  to  preceding  and  following  columns 
on  Figure  A-7.  Again,  the  hierarchy  below  the  nodes  on  this  graph  is  that  of  the  basic 
model. 

The  remainder  of  startup  would  be  modeled  in  the  same  way. 

Figure  A-68  is  the  new  subgraph  of  node  systemessages  on  the  top-level  graph, 
(Figure  A-63).  This  graph  is  divided  into  four  sections,  each  representing  a  cluster 
with  its  initiation  inputs  from  startup  and  its  termination  inputs  from  failure  or 
shutdown.  A  cycle  between  the  cluster  supervisors  of  clusters  0,  1,  and  2  and  the 
system  supervisor  in  cluster  3  handles  the  ping  and  ping  acknowledge.  One  node, 
CLUSTERS,  has  been  expanded  in  Figure  A'69.  This  graph  is  basically  one  half  of 
the  system  messages  graph  in  the  basic  model.  The  other  clusters  would  differ  only 
in  having  only  one  inport  and  one  outport  to  another  cluster  (clusters)  instead  of 
three  for  the  ping  and  ping  acknowledge.  The  hierarchy  below  these  graphs  is  the 
same  as  for  the  basic  model. 

Referring  again  to  Figure  A-63,  changes  similar  to  these  just  discussed  would  be 
needed  for  the  other  portions  of  the  model.  An  expanded  set  of  LPUs  would  expand 
the  grap! ,  i  of  nodes  normaloperations,  sensors,  and  pilotinput.  This  might 
well  require  a  grouping  of  related  processes  in  the  first  level  with  the  detail  pushed 
down  further  as  we  showed  for  startup  and  systemessages.  One  might  also  con- 
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sider  moving  the  failed  and  restarted  LPUs,  or  just  the  restarted  ones,  into  a  separate 
node.  If  LPUs  that  access  files  into  system  or  cluster  memory  were  included  in  an 
expanded  model,  addition  of  hierarchies  to  represent  the  BTBIM  memory  functions 
similar  to  those  in  startup  and  reconfigure  would  need  to  be  incorporated.  If  more 
than  one  failure  is  desired,  one  would  either  expand  or  duplicate  the  failure  through 
reconfiguration  chain.  Shutdown  would  be  expanded  in  a  manner  similar  to  that  done 
for  startup  and  system  messages. 

Finally,  if  one  determines  through  a  combination  of  calibration  and  simulation  rui._ 
on  an  expanded  model  (as  is  the  case  using  the  demonstration  3  scenario)  that  the 
Pl-bus  interface  units  do  not  have  a  significant  impact  on  performance  or  timing  of 
events  the  simulation  time  can  be  reduced  by  essentially  “shorting  out”  all  of  the 
diamond  shape  mes'^^age  graphs,  (see  Figure  A-21).  This  would  be  accomplished  by 
changing  the  node.class  attribute  of  the  parent  node  (on  Figure  A-20)  to  “leaf," 
ensuring  the  parent  node  is  mapped  onto  the  proper  Pl-bus,  and  setting  its  firing 
delay  to  that  used  in  the  subgraph.  This  can  be  done  throughout  the  model.  The 
result  is  that  for  each  of  these  changes,  the  simulation  software  has  only  one  node 
to  track  and  schedule  rather  than  five.  If  for  some  other  analysis  the  user  wishes  to 
reincorporate  the  detailed  subgraphs,  all  he  needs  to  do  is  change  the  parent  node’s 
node^class  attribute  back  to  “internal.”  The  subgraph  will  then  be  expanded  and  all 
other  attributes  of  the  parent  node  ignored. 
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6.  Conclusions 


In  Paragraph  1.1  it  was  stated  that  this  modeling  effort  was  the  first  phase  of  a 
two-phase  effort.  Development  of  this  model  was  to  be  followed  by  validation  (or  cal¬ 
ibration)  against  actual  measurements  of  performance  of  the  A  ARTS  demonstration 
3.  Validation  was  to  be  followed  by  expansion  of  the  model  to  a  full  PAVE  PILLAR 
mission  applications  architecture  to  be  used  to  investigate  data  transfer  functions. 
The  delay  of  demonstration  3  (and  completion  of  AARTS  development)  prevents  val¬ 
idation  of  the  model  against  measurements  of  the  actual  system.  (The  system  does 
not  yet  exist).  However,  the  model  has  been  continuously  validated  during  construc¬ 
tion  through  briefings,  technical  interchange  and  demonstrations  with  the  A.\RTS 
developer.  The  principle  measure  of  a  model  of  a  system  still  under  design  is  how 
well  (at  any  given  time)  the  model  represents  what  the  designers  visualize  as  their 
finished  product.  Since  design  decisions  continue  to  be  made  or  revised,  this  presents 
a  “moving  target”  that  requires  frequent,  if  not  continuous,  interchange  between  the 
modeler  and  the  developer.  That  interchange  was  achieved  in  this  effort  with  the 
graphical  presentation  of  the  ADAS  model  facilitating  communication.  The  results 
of  the  modeling  effort  have  highlighted  the  value  of  developing  an  executable  sim¬ 
ulation  of  a  system  as  the  design  and  development  progresses.  In  order  to  develop 
a  model  that  can  be  executed,  it  is  necessary  to  pursue  the  implications  of  design 
decisions  beyond  the  boundaries  of  the  specific  development  effort  (interface  with 
other  systems,  hardware  etc.).  This  broader  view  of  the  system  provides  insights  into 
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potential  clashes  or  mismatches  across  these  interfaces  that  can  lead  to  expensive 
and  time  consuming  corrective  action  if  not  discovered  until  late  in  the  development 
cycle.  These  insights  often  lead  to  design  changes  that  “invalidate”  the  model  version 
that  predicted  the  need  for  the  change.  This  requires  alteration  of  the  model  and 
revalidation  in  the  context  of  the  modified  design.  This  was  the  course  followed  in 
developing  the  basic  model  as  delivered. 

The  following  are  some  examples  of  the  benefits  obtained  from  this  modeling  effort, 
beyond  that  of  producing  a  model  to  serve  as  a  basis  for  further  expansion  and 
analysis  of  Advanced  Systems  Architectures.  These  examples  highlight  the  value  of 
simulation  of  a  component  (A ARTS)  during  design  of  that  component  in  a  system 
(AARTS,  LPUs,  plus  VAMPs)  context. 

Early  in  the  modeling  effort  ADAS  graphs  were  developed  for  the  initial  loading 
of  modules  that  were  very  much  like  the  current  model  of  passive  loading  of  ASO 
software.  The  modeling  weis  based  on  appendix  G  to  reference  17,  which  is  the 
description  of  SUROM  Processing  developed  by  Westinghouse  Electric  Corporation, 
the  developer  of  the  VAMP  hardware.  Following  this  document  the  ADAS  graphs 
assumed  that  after  completion  of  BIT  a  module  repeatedly  places  a  two- word  “ready” 
message  onto  the  Pl-bus  at  regular  intervals.  The  loader  (in  this  case  the  BTBIM), 
when  ready  to  load  the  module,  responds  with  a  four-word  message  (word  count, 
1750A  Data  Destination  Address  (DDA),  1750A  Execution  Start  Address  (ESA), 
and  Expected  Checksum).  Upon  receipt  of  this  message,  the  SUROM  software  sets 
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up  the  Pl-bus  interface  unit  to  point  to  the  DDA,  receives  the  bootstrap  loader, 
checksums  the  load,  and  transfers  control  to  the  ESA.  Then  the  bootstrap  loader 
proceeds  to  download  the  A  ARTS  software.  When  our  approach  was  communicated 
to  the  AARTS  development  team  we  were  informed  that  the  AARTS  design  would 
not  include  a  bootstrap  loader.  The  design  approach  was  to  load  the  ASO  software 
directly  following  the  four-word  message.  We  challenged  this  approach,  pointing  out 
that  the  reference  limits  the  maximum  word  count  in  the  four-word  message  (and 
presumably  the  download)  to  52K.  After  also  recognizing  that  the  one  word  (16-bit) 
word  count  would  not  accommodate  the  AARTS  file  size,  we  were  informed  during 
“final”  demonstration  of  the  startup  model  that  the  bootstrap  loader  was,  in  fact, 
necessary.  The  ADAS  graphs  were  redone.  This  example  highlights  the  fact  that 
the  modeling  effort  itself  benefits  and  supports  the  design  process.  Modeling  with  an 
architecture  tool  such  as  ADAS  can  identify  problems  at  the  interface  of  the  system 
being  designed  early  in  the  design  phase  (had  this  modeling  effort  started  earlier,  this 
problem  would  have  been  discovered  earlier)  rather  than,  as  is  too  often  the  case,  not 
until  integration  testing. 

During  the  effort  to  calculate  firing  delays  for  the  model  it  was  found  that  the  Pl-bus 
data  transfer  rate  we  were  instructed  to  use  was  five  times  faster  than  the  assumed 
memory  access  rate.  We  could  find  no  indication  of  a  buffer  in  the  PIBIU  and  this 
was  confirmed.  The  model,  as  it  now  stands,  includes  a  small  buffer  in  the  PIBIU,  a 
faster  memory  access  rate,  a  lower  Pl-bus  transfer  rate,  and  double-word  access  (32 


bit)  between  PIBIU  and  memory.  This  is  a  problem,  we  are  informed,  that  is  to  be 
corrected  in  this  manner  by  WEC,  the  hardware  developer. 

Both  of  the  preceding  examples  can  be  summed  up  in  a  single  observation:  Devel¬ 
opment  of  an  executable  ADAS  model  of  an  ongoing  design  brings  to  the  designers 
an  increased  awareness  of  constraints  imposed  by  hardware  or  interfacing  software 
systems. 

Finally,  some  insights  into  the  AARTS  design  have  been  derived  from  the  model¬ 
ing  effort  and  the  results  of  simulation  runs.  Two  have  already  been  mentioned  in 
Chapter  4.  These  are  the  dominance  of  checksum  times  in  software  loading  and  of 
“detection  of  failure”  in  reconfiguration.  Both  of  these  may  be  the  result  of  high 
estimates  of  the  time  consumed  by  processes  that  can  be  speeded  up.  The  checksum 
time  is  the  result  of  a  simple  estimate,  10  instruction  cycles  per  word,  and  can  be 
refined.  In  the  case  of  the  failure  detection,  it  may  be  no  more  than  a  bad  choice  of  a 
single  parameter,  Pulse_Timeout.  Table  6.1  shows  the  value  cited  for  this  parameter 
in  five  different  parts  of  Reference  11.  Three  of  these  are  found  in  a  subparagraph 
titled  “Limitations”  and  two  in  the  discussion  of  unit  processing.  They  vary  from 
three  pulse  periods  (.375  seconds)  to  ten  pulse  periods  (1.125  seconds).  The  latter 
is  used  in  the  model.  This  can  be  changed  by  simply  changing  the  value  of  the  at¬ 
tribute  firing.delay  on  node  detectmisngplse  in  the  subgraph  of  node  detect  in 
the  AARTS  graph.  Finally,  some  concerns  have  been  raised  about  the  behavior  of 
the  AARTS  itself. 
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Table  6.1.  Values  for  Pulse  Timeout 


(Source:  Reference  11) 


Software  Unit 

Processing  or  Limitation 

Page  Number 

Value 

SE.Kernal 

limitations 

24 

5  pulses 

SE.Cluster  Management 

text 

32 

5  pulses 

SE.Cluster  Management 

limitations 

37 

SE.System  Management 

limitations 

48 

SE.System  DB  Management 

text 

51 

3  pulses 

The  first  concern  is  with  startup  sequencing.  In  the  model,  as  delivered,  sequencing 
has  been  forced  in  the  hierarchy  below  the  node  that  represents  the  SMM  functions  in 
the  passive  loading  of  the  ASO  software.  In  order  to  accelerate  startup,  particularly  in 
a  larger  system  than  the  one  modeled  here,  one  may  want  to  allow  loading  of  multiple 
modules  in  parallel.  In  fact,  the  sequenced  loading  has  never  been  confirmed  to  us 
as  a  feature  of  the  AARTS  software.  It  was  a  “ground  rule”  we  were  given  to  work 
with.  In  such  a  case,  one  must  be  sure  that  the  MABIU  in  a  cluster  is  loaded  before 
any  CPU  module  commences  hot  backup  arbitration.  Otherwise  one  could  end  up 
with  more  than  one  system  supervisor. 

A  similar  concern  has  to  do  with  when  the  system  supervisor  commences  configuration 
(loading  LPUs  etc.).  The  model,  as  delivered,  will  not  commence  configuration  until 
all  models  have  loaded  and  started  ASO.  If  a  module  fails  on  startup  in  the  model  as 
configured,  configuration  will  not  take  place.  Since  we  were  instructed  to  consider  no 
BIT  failures,  this  is  not  a  problem  with  this  scenario.  However,  some  means  should 
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be  provided  for  the  system  supervisor  to  determine  when  to  start  configuration  that 
allows  for  failure  of  one  or  more  modules  in  the  startup  process.  The  algorithm 
must  be  such  that  it  does  not  cause  premature  loading  into  a  reduced  hardware 
configuration  when  the  full  configuration  actually  does  become  available.  This  is  not 
a  problem  in  the  demonstration  3  scenario  since  all  of  the  LPUs  could  be  run  in  a 
single  processor.  The  expanded  ADAS  model  of  phase  II  could  produce  performance 
assessment  of  alternative  approaches  to  this  feature. 
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Figure  A-1.  The  ADAS  System  Configuration 


Figure  A-2.  Top-Level  ADAS  Hardware  Graph 
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Figure  A-6.  Top  Level  ADAS  Software  Graph 
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Figure  A-8.  BTBIM  Active  Load 
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Figure  A-10.  SMM  Load  ASO  into  BTBIMs 
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Figure  A- 12.  CPU  Receive  BOOT  and  ASO  Load 
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Figure  A-15.  BTBIM  to  SMM 
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Figure  A-16.  BTBIM  to  Client 
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Figure  A- 19.  Arbitration  by  the  Winner  of  the  System  Supervisor  Role 
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Figure  A-20.  System  Supervisor  Load  LPUs 
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Figure  A-21.  Pl-bus  Transmission 
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Figure  A-22.  CPU  Load  Two  LPUs 
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Figure  A-23.  CPU  Load  on  LPU 
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Figure  A-26.  SMM  Download  LPUs  to  CPUs 
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Figure  A-27.  SMM  Download  on  LPU 
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Figure  A-28.  Configuration  Request  Placed  on  MAB 
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Figure  A-30.  MABIM  Place  Configuration  Request  on  Pl-bus 
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Figure  A-32.  Specialist  System  Messages 
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Figure  A-34.  Cluster 
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Figure  A-35.  System  Supervisor  Heartbeats 
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Figure  A-36.  Transmit  Ping  or  Pulse 
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Figure  A-37.  Pl-bus  Broadceist 


Figure  A-38.  Pl-bus  Transmission  with  Two  Outputs 
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Figure  A- 39.  Datafcw  of  Demonstration  3 
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Figure  A-41.  Normal  Operations 
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Figure  A-44.  Sensor  Management  LPU  in  CPU12 
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Figure  A-45.  Navigation  LPU  in  CPUll 
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Figure  A-47.  DGS  Interface  LPU  in  CPUll 
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Figure  A-48.  Detection  and  Reporting  of  Failed  CPU 
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Figure  A-49.  Reconfiguration 
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Figure  A-51.  Start  on  LPU  and  Transmit  Configuration  Report 


Figure  A-52.  To-Level  Graph  of  Shutdown  Process 
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Figure  A-53.  Cluster  2  Shutdown 
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Figure  A-56.  Cluster  1  Shutdown 
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Figure  A-57.  Pass  Cluster  1  Shutdown  Message 
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Figure  A-59.  Cluster  Supervisor  Load  ASl 
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Figure  A-60.  Hot  Backup  Arbitration 
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Figure  A-61.  Initiate  the  System  Supervisor 


Figure  A-62.  System  Supervisor  Arbitration 


Figure  A-63.  Top-Level  Graph  for  4  Clusters 


Figure  A-64.  Startup  Graph  for  4  Clusters 


Figure  A-66.  Graph  of  sukom  and  Active  Load 
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Figure  A-67.  Graph  of  A  SO  Passive  Load 
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Figure  A-68.  System  Messages  with  4  Clusters 
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